Differences between ARIA 1.0 and 1.1: Additions to ‘role’

The most recent Candidate Recommendation of the Accessible Rich Internet Applications (WAI-ARIA) specification was published on October 27, 2016. You can view the full document on the W3 website.

It’s important to note that this document is still subject to change with future publications and that these observations are meant to provide a high-level overview of broad level changes that will be important to be aware of going forward. As such, these details are likely to remain valid regardless. Also, many of these additions are minimally supported or not supported at all by browsers and assistive technologies as yet.

role=table and role=cell

The table roles are meant to handle constructs where a non-interactive data table is needed when the underlying markup does not use a standard HTML table element. This construct is static and is not meant to be interactive in the same way that role=grid is used.

The cell role is only valid within a role=table construct and is not valid within any other construct such as role=grid. The use of the roles table and cell are only valid within a construct that simulates a standard data table.


The role ‘term’ is meant to accompany and explicitly associate role=definition, which was missing in ARIA 1.0.

The attribute role=”term” must never be used on an interactive element, but instead must be used on container elements that include textual content or container elements that surround an interactive element (e.g., a link or button).

When role=definition is used, it must include aria-labelledby to point to the ID of the role=”term” element to explicitly associate the term to which the definition refers.


The role ‘figure’ is meant to surround user-navigable information, which may contain content ranging from graphical images to textual code fragments to mathematical equations. As such, the content of a figure is navigable in the same manner as a named region or landmark.

A figure may be explicitly named using either aria-labelledby or aria-label, or even reference an external caption using aria-describedby.


The role ‘feed’ was added in ARIA 1.1 to provide a mechanism for handling infinite scrolling regions within dynamic feed environments.

The role=feed container acts much like a named region or landmark, though it must only include first-level child roles with role=”article”. The Article role may of course, include any number of other roles and active elements.

Programmatic focus handling must be used to move focus between each role=article element within the role=feed container, and new role=article containers must be dynamically added to the beginning or end of the role=feed container when rendered.

The use of aria-describedby may be added onto each focusable role=article container to automatically announce the desired content within that article when it receives focus.

A focusable button should also be available at the end of the role=feed container that will dynamically load additional role=article elements when activated. This is needed for touchscreen devices and screen readers that use off-screen browse modes.


The role ‘searchbox’ was added to represent the same element type as an HTML input element that includes type=”search”.

The use of role=searchbox must be the only focusable element. This differs from role=”search”, which is meant to be a landmark that includes focusable active elements.

When role=searchbox is used, focus must be set to the role=searchbox element and the content of that element must then be directly editable. Since role=searchbox is a form field in the same manner as role=textbox, it must include an explicit label using either aria-labelledby or aria-label.


The role ‘switch’ was added as a type of simplified checkbox that can only handle two values, ‘false’ or ‘true’ (On or Off). The ‘switch’ role does not support aria-checked=”mixed”, which will default to ‘false’ if detected.

The use of role=switch must never include focusable active elements, but must instead be the only focusable element.

When role=switch is used, focus must be set to the role=switch element, and the spacebar (in addition to onClick) must be available to toggle aria-checked between “false” or “true”.

Since role=switch is a form field in the same manner as role=checkbox, it must include an explicit label using either aria-labelledby or aria-label.


The role ‘none’ was added to act as an alias for role=presentation, and both are the same and perform the same action. This was meant to provide clarity for those who were confused by the word “presentation.”

It was also proposed that role=”” also be available to perform the same behavior as role=”none” and role=”presentation”. However, this presented too many implicit role conflicts within browsers, assistive technologies, and framework development, so role=”” should never be used in place of role=”none” or role=”presentation”.

Reposted from SSBBart Group

Differences between ARIA 1.0 and 1.1: Deprecations & Additions

The most recent version of the Accessible Rich Internet Applications (WAI-ARIA) guidelines was published on October 27, 2016. You can view the full document on the W3 website.

It’s important to note that this document is still subject to change with future publications and that these observations are meant to provide a high-level overview of broad-level changes that will be important to be aware of going forward. As such, these details are likely to remain valid regardless. Also, many of these additions are minimally supported or not supported at all by browsers and assistive technologies as yet.

I’ll be posting a quick summary, and my thoughts here that will be divided between four blog posts. Today’s post will include the deprecations and some additions in ARIA 1.1.


In ARIA 1.1 the drag and drop attributes aria-grabbed and aria-dropeffect were slated to be deprecated.

The idea was to use native accessibility API features for drag and drop instead. However, in practice, since the accessibility API features for accessible drag and drop still don’t exist and likely won’t for several years, these attributes will continue to be supported on the Windows OS and reflected in the accessibility tree for some years to come until these APIs become available for use in development.

As such, the prior ARIA 1.0 guidance for making drag and drop accessible still remains valid at this time.



The aria-keyshortcuts attribute was added to convey which hotkey combinations are available to activate or focus on a particular element.

This is not like the accesskey attribute, where the modifier is handled by the browser and may differ between browsers, but instead represents the static shortcut combination that is programmed across all browsers.

In all cases where aria-keyshortcuts is used, these key commands need to be added by the developer using JavaScript, because there is no way for the browser or AT to know the expected functionality of all custom hotkey combinations. This attribute simply conveys the availability of these shortcuts and identifies what they are.

In short, adding the aria-keyshortcuts attribute without including the relevant scripting to make it work will result in shortcuts being conveyed to the user that do nothing when pressed.

At present, the aria-keyshortcuts attribute should only be used on focusable active elements.


The aria-roledescription attribute is meant to suppress the native role of an element and replace it with whatever the attribute string value states.

It’s important to note that the underlying role mapping remains the same in the browser and accessibility API, however assistive technologies like screen readers will announce only the value of aria-roledescription as the role of the element instead of the actual role that is mapped. At least, this is what the specification states.

However, some screen reader venders have already stated that they will not prevent the role from being conveyed to their users because this would cause too much confusion, but will instead announce both, thus forecasting that they have no intention to follow the spec in this matter. This will result in some screen reader vendors suppressing the role and others not, making this an unreliable attribute at best, and potentially an extremely dangerous feature if misused by conveying the wrong role or an incomprehensible role on critical interactive controls.


The aria-modal attribute was added to accompany the roles ‘dialog’ and ‘alertdialog’, to indicate to browsers and assistive technologies that the dialog is meant to be modal or non-modal.

If set to ‘true’, the background content in the accessibility tree should be hidden by browsers and assistive technologies so that only the modal content is perceived by the user.

If set to ‘false’ or left undefined, then the background content should not be hidden from the perception of AT users.

Currently this is only supported on iOS using VoiceOver iOS 9.X, so additional testing is needed to verify future levels of support.

To ensure forward compatibility for ARIA dialogs, all modal dialogs that use either role=”dialog”or role=”alertdialog” should include aria-modal=”true” to enable this support in the future. This should only be true for modal dialogs where the background content is not meant to be interacted with while the modal is open.


The aria-errormessage attribute takes an ID reference in the same manner as aria-describedby, and is only exposed when aria-invalid is set to ‘true’ on the same element. The use of a live region attribute such as aria-live=”polite” on the error message container element is optional.


The aria-placeholder attribute is meant to simulate the HTML5 behavior of the placeholder attribute and make it valid within other simulated control types and roles where the HTML5 placeholder attribute is not valid.

All scripting, styling, and functionality of the use of this attribute must be implemented manually by the developer since the attribute itself is not meant to have any effect on browser functionality.

The aria-placeholder attribute and the HTML5 placeholder attribute should not be used together on the same element, nor should aria-placeholder be used on native form controls where the HTML5 placeholder attribute is appropriate.


The aria-current attribute is meant to convey to an assistive technology that this is the current item within an associated collection of elements.

When set to “false”, “”, or the attribute is undefined, nothing is exposed to assistive technologies. Otherwise, aria-current accepts a list of token values that convey the type of item being represented in the set. These are listed below:

  • page = Represents the current page within a set of pages
  • step = Represents the current step within a process
  • location = Represents the current location within an environment or context
  • date = Represents the current date within a collection of dates
  • time = Represents the current time within a set of times
  • true = Represents the current item within a set

aria-current must never be used as a substitute for aria-selected where aria-selectedis a required attribute for specific roles.

You can use aria-current in addition to aria-selected when aria-current conveys that one node is currently active, regardless of which element is selected. For example: when a language selector where aria-current conveys the currently chosen language, and arrowing through the listbox conveys which language option is currently selected.


The aria-details attribute takes an ID reference in the same manner as aria-describedby, and is meant to provide access to a more comprehensive description (when available) that may include additional active elements.

As such, aria-details takes precedence over aria-describedby if both are present on the same element. However, it is necessary for the user to navigate to the container referenced by aria-details to view and interact with the content of that description. This differs from aria-describedby, which is part of the naming calculation for the element that has focus, and where it is not necessary to move focus away from that element to hear the description. In contrast, aria-details is not included in the naming calculation for setting the Description property, and the user must instead navigate away from the focused element to view the detailed description.

Reposted from SSBBart Group

Obama Administration Releases Major Update To Section 508, Mandates Web Accessibility for People with Disabilities

The Obama Administration has just released a major regulatory rule updating the standards federal agency websites will need to meet in order to adhere to the requirements outlined in Section 508 of the Rehabilitation Act, according to the Access Board’s Twitter account.

OMB just cleared @AccessBoard final rule updating standards & telecom guidelines! Rule to be published soon – details to follow.

The new regulations require federal agencies to adjust procurement procedures so that all new websites adhere to the Web Content Accessibility Standards (WCAG 2.0), an expansive, but carefully-developed specification that ensures usability while allowing developers considerable flexibility. The rule brings U.S. policy in line with that of over thirty countries and is the result of over a decade of collaboration between the technology industry, the disability community, and businesses.

We expect this announcement to have significant implications for a wide range of businesses and organizations. Recent federal court cases and Justice Department actions indicate that this rule will be the de facto standard for private entities despite the fact that the official rulemaking for private entities has been delayed until 2018.

The U.S. Access Board submitted the regulations on October 24th, 2016. The Office of Management and Budget approved the final rule on January 5th, 2017. This is the first update to the initial regulations, which were published 16 years ago.

EveryBill will release an expanded analysis in the coming days.

Learn more about accessibility here.


In a move welcomed by disability groups and advocates, the U.S. Access Board has updated their accessibility requirements for Information and Communication Technology (ICT) within Section-508 of the Rehabilitation Act, to bring it into line with European and WCAG (Level A, AA) standards.

Access stamp

Access stamp

The new rule was announced 9 January 2017 and is in response to market trends and innovations, such as the convergence of technologies. The refresh also harmonizes these requirements with other guidelines and standards both in the U.S. and abroad, including standards issued by the European Commission and the Web Content Accessibility Guidelines (WCAG) the globally-recognised consensus standard for web content and ICT.

The U.S. Access Board’s final ruling(link is external) also refreshes guidelines for telecommunications equipment subject to Section 255 of the Communications Act. Indeed, the ruling references Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 and applies them not only to websites but also to electronic documents and software.

“This is a key development to ensure that ICT which is developed, procured, maintained or used by federal agencies in the US is accessible to, and usable by, people with disabilities,” says Natalie Collins, the Deputy CEO of Media Access Australia.

“Specifically, they have updated the Act to deal with convergence and the functionality according to disability rather than by product type,” she said. “Revisions are also made to improve ICT usability, including interoperability with assistive technologies, and to clarify the types of ICT covered, such as electronic documents, which is a very welcome move.”

“Hopefully, what will happen is that more and more software apps that are developed by US vendors which are required to make their apps accessible in the US, will flow through to Australia, benefiting those with a disability here as well,” adds Collins.

For further information on this new development in the US, you can visit the Access Board’s website(link is external).

Companies Face Lawsuits Over Website Accessibility For Blind Users

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 suits named above have been dismissed, according to court dockets, which don’t reflect if a private settlement was reached. Toys “R” Us said it is looking for ways to make its website more accessible. The other companies had no comment or didn’t respond to a request for comment.

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.”

 Federal appellate courts have been divided on the issue, with some finding that all websites must comply with disability standards, and others contending that websites only fall under the ADA if they have a “nexus” to a brick-and-mortar business. Mr. Danielsen said there is no data as to how many websites don’t accommodate blind users.

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.”

How the Web Became Unreadable

I thought my eyesight was beginning to go. It turns out, I’m suffering from design.

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.

Google’s App Engine console before — old-fashioned but clear
Google’s App Engine console after — modern, tiny, and pallid

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.

Contrast as modeled in 2008

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.

Apple’s guidelines for developers.

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

Business Websites Need to Be ADA Compliant or Risk Being Sued

If your business website is not in compliance with the American Disabilities Act (ADA), it needs to be – soon!

Businesses across the country are being sued for millions of dollars for not having websites that meet the minimum compliance requirements set forth by the ADA Law of 1990 and the Department of Justice technical memorandum addressing website accessibility.

Just recently, a group of law firms has begun suing businesses that are not in compliance with the ADA Law and the Web Content Accessibility Guidelines, or WCAG, which outlines enforceable regulations.

Companies like:

  • Target,
  • Bath & Body Works LLC,
  • Giant Food Stores LLC,
  • Build-A-Bear Workshop Inc.,
  • Express Inc.,
  • Office Depot Inc.,
  • DSW Inc.,
  • American Eagle Outfitters Inc., and
  • JC Penny

have all been served.

In Target’s case, the settlement was for $6,000,000 and $20,000 was paid to a non-profit corporation dedicated to helping the blind.

But it’s not just blind consumers that businesses need to consider. The ADA Law and the Web Content Accessibility Guidelines have regulations in place that calls for websites to accommodate individuals who are deaf, visually and/or audibly impaired. All of these individuals have specific requirements that need to be met when they engage with your website online and it better be accessible or else you may find yourself on the other end of a lawsuit.

Believe it or not, your business website needs to be built with specific features so individuals with various disabilities are able to access it and navigate through it like anyone else. If not, you’re placing your business in jeopardy.

What Does a Business Website Need to be ADA Compliant?

Businesses need to ensure they are providing the same information to whoever comes upon their websites. When it comes to visitors with disabilities, they should be able to engage in the same types of transactions that are available to the average public consumer.

Website compliance, in terms of the ADA Law and WCAG, is based on the needs of individuals who are blind, deaf, visually and/or audibly impaired.  Each of these groups has specific needs and, in most instances, these needs are unique to that group.

Part of the settlement in the Target case called for the company to ensure “that blind guests using screen-reader software may acquire the same information and engage in the same transactions as are available to sighted guests with substantially equivalent ease of use.”

A screen reader is one of two specific mechanical devices that are used to support disability groups under the law. The other is a braille reader.  Constructing a website that works with these devices is an absolute requirement.  Additionally, there are other nuances, like colors, screen size adjustment, and fonts, all of which must be addressed.

Other Key Website Requirements to Protect Your Business

There are hundreds of features that need to be evaluated on business websites to ensure compliance. Five primary areas that need to be evaluated to determine whether or not a website meets ADA requirements include:

  1. Text Tags: Do your images include Alt. text tags? These are needed so screen readers and braille readers can interpret the image.
  2. PDF Files: If your website includes PDF files for reading or downloading, is there an HTML or Rich Text Format alternative? Since PDF’s are basically images, they need to have text equivalents so readers are able to interpret them.
  3. Web Browser Adjustments: Does your website allow the images, colors, and fonts to be adjusted by the web browser being used by the viewer? Being able to adjust these three elements of your website is important for visually impaired viewers who may need different contrasts and sizes to see what’s on your website.
  4. Size Adjustments: Does your website allow size adjustment of its content? Often impaired viewers cannot take in the entire screen and need to focus on a specific area by expanding it to interpret the information.
  5. Text Captions: Do your web pages have text captions, i.e. title tags, meta descriptions, and H1-H5 tags that summarize the pages, images, and paragraphs of the website? This is required to make videos and audio tracks understandable to those individuals who may have visual or auditory challenges.

How to Get Started?

The first step you need to take to protect your business is to have your website analyzed for ADA compliance.

We know what to look for and how to add or fix what’s required to keep your business safe.

Designing Accessible Web Forms

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 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/.

Tips and Tricks to Improve Web Accessibility

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.

<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.


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.

Creating an ADA-compliant website

Title III of the Americans with Disabilities Act (ADA) requires that businesses and nonprofit services providers make accessibility accommodations to enable the disabled public to access the same services as clients who are not disabled. This includes electronic media and websites. While the ADA applies to businesses with 15 or more employees, even smaller businesses can benefit from ensuring that their websites are ADA compliant. Doing so opens your company up to more potential clients and limits liability. Web developers should include ADA compliant features in the original site and application plans.

This is particularly important when working for a government agency or government contractor, as these organizations must follow web accessibility guidelines under Section 508 of the Workforce Rehabilitation Act of 1973. Although ADA and Section 508 compliance are different, the published checklist for Section 508 compliance offers insight into ways to make websites accessible for people with disabilities, and thereby work toward ADA compliance.

To check your website for accessibility, you can use the accessibility checklist published by the U.S. Department of Health and Human Services (1194.22 Web-based intranet and internet information and applications):

  • Every image, video file, audio file, plug-in, etc. has an alt tag
  • Complex graphics are accompanied by detailed text descriptions
  • The alt descriptions describe the purpose of the objects
  • If an image is also used as a link, make sure the alt tag describes the graphic and the link destination
  • Decorative graphics with no other function have empty alt descriptions (alt= “”)
  • Add captions to videos
  • Add audio descriptions
  • Create text transcript
  • Create a link to the video rather than embedding it into web pages
  • Add a link to the media player download
  • Add an additional link to the text transcript
  • The page should provide alternative links to the Image Map
  • The <area> tags must contain an alt attribute
  • Data tables have the column and row headers appropriately identified (using the <th> tag)
  • Tables used strictly for layout purposes do NOT have header rows or columns
  • Table cells are associated with the appropriate headers (e.g. with the id, headers, scope and/or axis HTML attributes)
  • Make sure the page does not contain repeatedly flashing images
  • Check to make sure the page does not contain a strobe effect
  • A link is provided to a disability-accessible page where the plug-in can be downloaded
  • All Java applets, scripts and plug-ins (including Acrobat PDF files and PowerPoint files, etc.) and the content within them are accessible to assistive technologies, or else an alternative means of accessing equivalent content is provided
  • When form controls are text input fields use the LABEL element
  • When text is not available, use the title attribute
  • Include any special instructions within field labels
  • Make sure that form fields are in a logical tab order
  • Include a ‘Skip Navigation’ button to help those using text readers

(Courtesy U.S. Department of Health and Human Services)

If the site meets all these criteria, it is likely accessible to people with disabilities. The best test is to obtain feedback on the site’s ease of use from people who are blind, deaf, and have mobility disabilities, then address their feedback with site improvements.

When collecting feedback, ask users what type of adaptive technologies (AT) they use. This will allow you to cater your website to your particular clientele, and will help you appoint resources toward the best compliance options. Navigating the Internet is particularly challenging for people with limited or no vision. Many blind people use specialized web browsers and software that works with standard web browsers, like Firefox, that have features that enable users to maximize their Internet use and experience. This screen reading software reads the HTML code for websites and gives the user a verbal translation of what is on screen.

Web developers need to keep this in mind when creating websites. The best screen readers use naturalized voices and alter tone and inflection based on HTML tags, so choose layout elements carefully. It is also important to keep in mind that navigation is significantly slower when using a screen reader than it is for sighted people. Sighted people don’t have to wait for the reader to get to the link we want- we spot links quickly and are able to navigate to our sought items, often without having to do any reading at all. Minimizing graphics also helps shorten reading times and speed navigation for disabled users.

Don’t wait for user feedback to discover the gaps in your website’s accessibility. Conducting your own trial run will tell you where the site has too many graphics, and where HTML tags don’t convey information accurately. It’s wise to do trial runs with as many of the most popular screen readers available:

Development tools and tutorials exist to help web designers meet compliance standards and go beyond to offer disabled users an enjoyable experience (and keep them coming back). Check out the following for more information:

Then make your job easier with these web accessibility development tools:

You probably won’t have to check your site with all of the available evaluation tools out there, but it is a good idea to do so for the most common web browsers. Just as accessibility software makes it easier for people with disabilities to navigate the Internet, these tools make it easier for developers to ensure accessibility from the start. When you think you’ve mastered it, go through the Section 508 compliance checklist to ensure you’ve met every goal.