All told, about 40 nearly identical cases have landed in front of the same federal judge,Arthur Schwab, all brought by one local law firm, Carlson Lynch Sweet Kilpela & Carpenter LLP.

Nationwide, more than 240 businesses have been sued in federal court since the start of 2015, concerning allegedly inaccessible websites, according to law firm Seyfarth Shaw LLP. Most settle quickly, for between $10,000 and $75,000, lawyers involved say, with the money typically going toward plaintiffs’ attorneys’ fees and expenses.

The Justice Department, which enforces the Americans with Disabilities Act, has delayed since 2010 releasing technical guidelines as to how websites should comply, most recently putting it off until 2018. The delay has led to “complete mayhem,” said Minh Vu,a Seyfarth Shaw partner who represents companies in disability-access cases.

A Justice Department spokesman declined to comment on the guidelines, but noted public settlements the agency has reached with companies, including tax-preparation service H&R Block and online grocer Peapod, requiring them to make websites accessible.

Disability-rights advocates and plaintiffs’ lawyers say the litigation points to a real issue: making sure those with disabilities have the same freedom to enjoy the internet as everyone else.

“Blind people are not going to be able to thrive and live the lives they want to live if they don’t have equal access to websites,” said Christopher Danielsen, spokesman for the National Federation of the Blind. He said most websites have barriers for the blind, who rely on software to read the content of webpages aloud. Such services can be free or cost upward of $1,000, depending on the sophistication.

Defense lawyers and industry groups counter that while the underlying issues are important, the suits are a legal-fee shakedown and don’t help improve accessibility. “You find entrepreneurial lawyers who are always looking for the next great cause of action,” said Steven Solomon, a defense lawyer at GrayRobinson PA in Miami.

Public businesses have long been required to be accessible to the disabled under the ADA, signed into law in 1990. Websites, however, weren’t expressly included in the law as a place of “public accommodation.”

Miami-area resident Juan Carlos Gil, who is legally blind and wheelchair-bound because of cerebral palsy, isn’t content to wait for the legal landscape to clear. Mr. Gil has sued more than 30 businesses this year alleging their websites violate the law, including women’s retailer Anthropologie Inc., grocery chain Winn Dixie Stores Inc., and Burger King Corp. “These are big corporations…that honestly they don’t care,” the 34-year-old said.

Winn-Dixie said it doesn’t comment on open litigation. Anthropologie and Burger King didn’t respond to a request for comment.

Mr. Gil said he faces obstacles online 90% of the time. When websites aren’t coded correctly, screen readers get stuck, simply saying “image” or “blank” aloud, without continuing across the page. Proper headers and text embedded behind images help blind users navigate sites.

Retrofitting websites that aren’t built correctly can run into the tens of thousands of dollars or more for companies, experts say.

A para athlete, Mr. Gil said he recently spent $200 on wheels for his racing wheelchair while competing in London, only to later realize he had ordered the wrong item because the website was difficult to use.

Mr. Gil is represented by Miami attorney Scott Dinin, who has sued at least 108 mall retailers, restaurants, banks and others during the past year in the Southern District of Florida. “All we’re looking for is, are you going to be inclusive, or exclude people?” Mr. Dinin said.

He and other plaintiffs’ lawyers, including Bruce Carlson of Carlson Lynch and C.K. Leein New York, are quick to note that the website suits aren’t big moneymakers, but decline to discuss the economics.

For every company sued, several more receive letters seeking an out-of-court settlement.

A restaurant trade group recently alerted its members to a typical Carlson Lynch demand letter that invites companies to call the law firm before hiring experts “to explore a far more cost-effective and pragmatic approach to resolving these issues.” The letters include a report of red flags on a company’s website derived from a disability-access scanning program.

Mr. Carlson said his firm has sent “many hundreds of letters” and only targets larger companies, because he believes that is more likely to make industries aware of the issues than suing mom-and-pop businesses.

Judges often push the lawsuits into mediation, which then are resolved in private settlements, according to a review of nationwide court dockets. The settlements frequently include a timeline in which a company agrees to improve its website and undergo future monitoring, lawyers involved say, but some entail little more than paying attorneys fees. So far, the suits primarily target websites, but lawyers expect claims against mobile applications could be on the horizon.

Mr. Danielsen with the National Federation of the Blind said the organization has filed some lawsuits but prefers to work collaboratively with companies. “There are millions of websites, literally,” he said. “Nobody is going to sue everybody.”

It’s been getting harder for me to read things on my phone and my laptop. I’ve caught myself squinting and holding the screen closer to my face. I’ve worried that my eyesight is starting to go.

These hurdles have made me grumpier over time, but what pushed me over the edge was when Google’s App Engine console — a page that, as a developer, I use daily — changed its text from legible to illegible. Text that was once crisp and dark was suddenly lightened to a pallid gray. Though age has indeed taken its toll on my eyesight, it turns out that I was suffering from a design trend.

There’s a widespread movement in design circles to reduce the contrast between text and background, making type harder to read. Apple is guilty. Google is, too. So is Twitter.

Typography may not seem like a crucial design element, but it is. One of the reasons the web has become the default way that we access information is that it makes that information broadly available to everyone. “The power of the Web is in its universality,” wrote Tim Berners-Lee, director of the World Wide Web consortium. “Access by everyone regardless of disability is an essential aspect.”

But if the web is relayed through text that’s difficult to read, it curtails that open access by excluding large swaths of people, such as the elderly, the visually impaired, or those retrieving websites through low-quality screens. And, as we rely on computers not only to retrieve information but also to access and build services that are crucial to our lives, making sure that everyone can see what’s happening becomes increasingly important.

We should be able to build a baseline structure of text in a way that works for most users, regardless of their eyesight. So, as a physicist by training, I started looking for something measurable.

It wasn’t hard to isolate the biggest obstacle to legible text: contrast, the difference between the foreground and background colors on a page. In 2008, the Web Accessibility Initiative, a group that works to produce guidelines for web developers, introduced a widely accepted ratio for creating easy-to-read webpages.

To translate contrast, it uses a numerical model. If the text and background of a website are the same color, the ratio is 1:1. For black text on white background (or vice versa), the ratio is 21:1. The Initiative set 4.5:1 as the minimum ratio for clear type, while recommending a contrast of at least 7:1, to aid readers with impaired vision. The recommendation was designed as a suggested minimum contrast to designate the boundaries of legibility. Still, designers tend to treat it as as a starting point.

For example: Apple’s typography guidelines suggest that developers aim for a 7:1 contrast ratio. But what ratio, you might ask, is the text used to state the guideline? It’s 5.5:1.

Google’s guidelines suggest an identical preferred ratio of 7:1. But then they recommend 54 percent opacity for display and caption type, a style guideline that translates to a ratio of 4.6:1.

The typography choices of companies like Apple and Google set the default design of the web. And these two drivers of design are already dancing on the boundaries of legibility.

It wasn’t always like this. At first, text on the web was designed to be clear. The original web browser, built by Berners-Lee in 1989, used crisp black typeon a white background, with links in a deep blue. That style became the default settings on the NeXT machine. And though the Mosaic browser launched in 1993 with muddy black-on-gray type, by the time it popularized across the web, Mosaic had flipped to clear black text over white.

When HTML 3.2 launched in 1996, it broadened the options for web design by creating a formal set of colors for a page’s text and background. Yet browser recommendations advised limiting fonts to a group of 216 “web-safe” colors, the most that 8-bit screens could transmit legibly. As 24-bit screens became common, designers moved past the garish recommended colors of the ’90s to make more subtle design choices. Pastel backgrounds and delicate text were now a possibility.

Yet computers were still limited by the narrow choice of fonts already installed on the device. Most of these fonts were solid and easily readable. Because the standard font was crisp, designers began choosing lighter colors for text. By 2009, the floodgates had opened: designers could now download fonts to add to web pages, decreasing dependency on the small set of “web-safe” fonts.

As LCD technology advanced and screens achieved higher resolutions, a fashion for slender letterforms took hold. Apple led the trend when it designated Helvetica Neue Ultralight as its system font in 2013. (Eventually, Apple backed away from the trim font by adding a bold text option.)

As screens have advanced, designers have taken advantage of their increasing resolution by using lighter typeface, lower contrast, and thinner fonts. However, as more of us switch to laptops, mobile phones, and tablets as our main displays, the ideal desktop conditions from design studios are increasingly uncommon in life.

So why are designers resorting to lighter and lighter text? When I asked designers why gray type has become so popular, many pointed me to the Typography Handbook, a reference guide to web design. The handbook warns against too much contrast. It recommends developers build using a very dark gray (#333) instead of pitch black (#000).

The theory espoused by designers is that black text on a white background can strain the eyes. Opting for a softer shade of black text, instead, makes a page more comfortable to read. Adam Schwartz, author of “The Magic of CSS,” reiterates the argument:

The sharp contrast of black on white can create visual artifacts or increase eye strain. (The opposite is also true. This is fairly subjective, but still worth noting.)

Let me call out the shibboleth here: Schwartz himself admits the conclusion is subjective.

Another common justification is that people with dyslexia may find contrast confusing, though studies recommend dimming the background color insteadof lightening the type .

Several designers pointed me to Ian Storm Taylor’s article, “Design Tip: Never Use Black.” In it, Taylor argues that pure black is more concept than color. “We see dark things and assume they are black things,” he writes. “When, in reality, it’s very hard to find something that is pure black. Roads aren’t black. Your office chair isn’t black. The sidebar in Sparrow isn’t black. Words on web pages aren’t black.”

Taylor uses the variability of color to argue for subtlety in web design, not increasingly faint text. But Taylor’s point does apply — between ambient light and backlight leakage, by the time a color makes it to a screen, not even plain black (#000) is pure; instead it has become a grayer shade. White coloring is even more variable because operating systems, especially on mobile, constantly shift their brightness and color depending on the time of day and lighting.

This brings us closer to the underlying issue. As Adam Schwartz points out:

A color is a color isn’t a color…
…not to computers…and not to the human eye.

What you see when you fire up a device is dependent on a variety of factors: what browser you use, whether you’re on a mobile phone or a laptop, the quality of your display, the lighting conditions, and, especially, your vision.

When you build a site and ignore what happens afterwards — when the values entered in code are translated into brightness and contrast depending on the settings of a physical screen — you’re avoiding the experience that you create. And when you design in perfect settings, with big, contrast-rich monitors, you blind yourself to users. To arbitrarily throw away contrast based on a fashion that “looks good on my perfect screen in my perfectly lit office” is abdicating designers’ responsibilities to the very people for whom they are designing.

My plea to designers and software engineers: Ignore the fads and go back to the typographic principles of print — keep your type black, and vary weight and font instead of grayness. You’ll be making things better for people who read on smaller, dimmer screens, even if their eyes aren’t aging like mine. It may not be trendy, but it’s time to consider who is being left out by the web’s aesthetic.

Reposted from
Kevin Marks
http://kevinmarks.com

Why are forms such tricky business? Perhaps because there are lots of very unforgiving pieces of code involved. It might have to do with the troublesome process of creating an interaction between your form and another computer-based entity, such as another form, or a database. And of course, the trickiest interaction of all takes place between your form and a human being.

But forms are also a great opportunity to improve accessibility because they are where you find out you have a problem. If you give users an article to read and you never hear from them, you might assume that they got the information they needed, and everything was fine. But when a user submits a form with crazy input in it—why do these people put the zip code in the city field?—an accessibility alarm should sound.

Logical Layouts

Forms need to be designed in a logical, consistent way. Make sure the question or description for each input field (a text box, checkbox, or select menu, for example) is on the same line as the input field itself.

Place the label consistently on the same side of the input field, and be sure to explicitly tell the user which bits of information are required. Don’t be subtle! Many web designers rely on color or bold text alone to indicate which items are required fields. Obviously, this technique is of little help to a user who is blind or visually impaired.

We recommend actually making the word Required part of the label for each mandatory field. This practice will benefit users who have low vision, who are color-blind, or who are accessing the site with a screen reader. It is also helpful to users with cognitive disabilities. In general, being consistent and logical in form design will help all users.

Labeling Form Controls

Use the “Label” Tag for Form Controls

Especially for users who access your site using screen readers, it can be extremely difficult or impossible to know what is required in input fields in forms. A user moving through an incorrectly marked up form may hear no more than “Edit edit edit radio button not checked radio button not checked Submit button.”

To make the form usable, explicitly label each control by enclosing the text associated with it in a <label for=””> tag. Then, add an ID attribute to the input field and make both the ID and FOR equal to the same value. Note: ID values must be unique. You cannot give multiple inputs in a form the same ID value.

Avoid Radio Buttons

Radio buttons are not supported consistently by all versions of browsers, screen readers, and combinations. A correctly labeled and tagged set of radio buttons is a very difficult control for users of screen-reading technology. If a “choose only one” situation is called for, a select menu is preferable.

If you must use radio buttons, remember to label them with the “Label for” tag. When radio buttons are used, each radio button in the group has the shared name, but a unique ID. Each radio button in the group has a unique label, as well.

Select Menus

Label Select Menus Inside and Out

The default item in a select menu (also known as a “pulldown menu” or “combo box”) should clearly define the purpose of the menu. For example, “Select Age Range” is preferable to “18-25.” Many screen readers and browsers fail to connect the label with the menu, so users may never see the label.

Keyboard Accessibility

Many users do not use a mouse, but instead use the keyboard to move through the form. One of the main barriers to keyboard accessibility can be the use of client-side scripts, small sections of programming code that run in the user’s browser instead of on the web site’s computer. Be cautious about using client-side scripts to change the browser’s focus, manipulate the data, or submit forms. These techniques can make a form impossible to use with the keyboard alone.

Make sure select menus work with the keyboard as well as with the mouse. Some menus are configured, usually with a client-side script, to take an action as soon as the user has selected an item. Since the keyboard user must pass through the first four items to select the fifth, this select menu does not work for them. The screen-reader-user has reading and navigating tied together in one action, so this user is not only yanked away to the wrong page, he or she does not know what it will be.

Instead, provide a normal submit button that the user can select at leisure, after reviewing all the menu items.

Checkboxes

Checkboxes are a simple control and should be labeled as described above. But they are worth handling with special caution because they often appear after explanatory text or a long question. If the checkboxes’ labels include only the answers and not the original question, the user will miss important information.

A designer using common sense might label a choose-all-that-apply question in a technically correct manner, but might fail to make them usable to test-takers.

Solution: Use the Fieldset Tag

A better approach to the checkbox problem is to use a “fieldset” tag, and then create a “legend” for the fieldset. A fieldset tag allows the designer to treat several different input fields as a group, with a shared description.

Testing Your Form

It is nearly impossible to know whether you’ve marked up your form correctly without testing it with a screen reader. Use more than one screen reader. They can sometimes make good guesses about bad markup and mask a problem.

Read the form by tabbing from one input field to another without trying to fill out the form. Fix any errors you find.

Now test the form by entering the screen reader’s “forms mode” and attempting to fill out the form. You may find quite different results. Fix any additional errors you discover.

The Bottom Line

In summary, if you lay out your forms logically and consistently, make proper use of labels, and avoid client-side scripts and radio buttons, your web forms will be much more accessible to users who are visually impaired.

For more information about creating accessible web sites, explore the Creating Accessible Websites area of the AFB site, or visit the World Wide Web Consortium’s Web Content Accessibility Guidelines at http://www.w3.org/TR/WCAG20/.

1. Relative Font Sizes

Use relative font sizes expressed in percentages or ems, rather than absolute font sizes expressed in points or pixels. This practice allows users to make the text larger or smaller as desired—an important feature for users with low vision.

2. Provide Alternative Text for Images

It is absolutely necessary to provide text equivalents for all meaningful graphics. If the graphic includes text, be sure that the alternative text (often referred to as an “alt tag”) supplies all of the words.

Example:
<img src=”graphic.gif” alt=”Acme – supplying widgets since 1945″ width=”50″ height=”20″>

That said, providing “alt” text for spacers or placeholding graphics subjects the speech user to meaningless information. Spacers or graphics used only for positioning should be labeled with alt=” ” (quote, space, quote). Note that you should never completely omit the alt tag, even for placeholding graphics. This omission subjects the speech user to hearing the file name of the image.

If you are in doubt as to whether or not to describe an image with an alt tag, do it.

3. Name Links Carefully

Users often move through a page by tabbing from link to link. Never use “Click here” or “Learn More” as the text for your links. “Download New Version” is self-explanatory.

4. Explicitly State Information

Do not use indentation or color alone, for example, to convey meaning.

Example:

Indicating required fields in a form by making them bold is bad.
Indicating required fields by using a phrase such as “required” is good.

5. Label Forms Properly

Create a predictable, consistent interface for your users. For example, make sure the question or description is consistently on the same side of its control. Ideally, place the question or label on the same line as the input field itself.

Enclose the label associated with an input field in a <label for=””> tag, or wrap it in a fieldset.

6. Provide Skip Links

Skip links allow the speech software or braille user to bypass information that is repeated on every page, such as navigation bars. Speech and braille users generally read the page from top to bottom and consequently are subjected to repeated information before reaching the heart of the page. Skip links allow these users to jump past the repetitive navigation links to get to the main content on the page.

To implement skip links, place a link before the repeated information as follows:

<a href=”#content”><img src=”empty.gif” height=”15″ border=”0″ alt=”Skip Main Navigation” width=”5″></a>

and place an anchor at the beginning of unique copy:

<a name=”content”></a>

The image can be transparent so that the visual display is not affected, but speech and braille users can hear the alt tag reading “skip main navigation”.

It is also possible to use a text link that literally says <a href=”#content”>skip main navigation</a>, if you prefer. We do not recommend using an “invisible” text link, like a single space or underscore. That technique relies on the link’s title to provide accessibility, and not all screen readers provide the link title to the user.