Website Accessibility & Certification

Welcome to our blog on Website Accessibility where we will be discussing the laws concerning the Americans with Disabilities Act (ADA), Web Content Accessibility Guidelines (WCAG) 2.0, Section 508 Requirement and Responsibilities (Section 508) and how to design your websites to be compliant and achieve certification.




All organizations, Federal and State agencies, and educational institutions should look to the WCAG 2.0 guidelines to provide guidance on how to make products accessible.

Section 508 is currently undergoing a refresh and will be requiring compliance with these guidelines for all Federal agencies and those who are selling to the Federal Government. The Department of Justice is also looking to these guidelines for the set of guidelines that organizations will need to comply to under The Americans with Disabilities Act (ADA).


U.S. government websites and applications and those developed using US Federal funds must comply with Section 508. Many state agencies and corporations have adopted the standards.


The ADA standards apply to commercial and public entities that have “places of public accommodation” which includes the internet. The DOJ is currently determining the specific regulations but that does not mean website discrimination will be tolerated. The DOJ’s public position was clarified in the following statement made during the Netflix case:

“The Department is currently developing regulations specifically addressing the accessibility of goods and services offered via the web by entities covered by the ADA. The fact that the regulatory process is not yet complete in no way indicates that web services are not already covered by title III.”
— Statement of Interest of the United States Department of Justice in NAD v. Netflix (page 10)

Who does the law affect?

  • Americans with disabilities and their friends, families, and caregivers
  • Private employers with 15 or more employees
  • Businesses operating for the benefit of the public
  • All state and local government agencies

How the Updated Section 508 Standards Map to WCAG 2.0

On January 18, 2017, the United States Access Board, also known as the Architectural and Transportation Barriers Compliance Board, updated two acts related to making technology accessible to people with disabilities. The first modification is to the Electronic and Information Technology Accessibility Standards within Section 508 of the Rehabilitation Act of 1973.


Section 508 stipulates requirements on how federally funded entities develop, procure, maintain, or otherwise use information technology. The impetus for the action was a desire to “refresh” the nearly 20-year-old, static accessibility standards within each act, adopting a more modern and internationally recognized standard. It was determined that the Web Content Accessibility Guidelines (WCAG) 2.0 was best suited to fulfill this requirement.


In “Section 508 Refresh: How WCAG Impacts Federal Website Accessibility Requirements,” Microassist’s Hiram Kuykendall summarizes and maps the Section 508 references to the internationally recognized WCAG, including multiple links to the new federal Information and Communication Technology (ICT) Standards and Guidelines and to WCAG’s success criteria.




We live in an era when information is readily available no matter where we go, thanks to mobile phones and the proliferation of apps for every possible need or interest.

Yet one of the largest audiences for mobile apps is still often overlooked.

In the United States, one out of every five adults has a disability, according to a 2015 study published by the Centers for Disease Control and Prevention. That’s about 22% of the population.

What’s more about 10% of the world’s total population, or roughly 650 million people, live with a disability. Looked at another way – people with disabilities are the world’s largest minority group.

Designing universally accessible mobile apps, however, remains an afterthought in many cases.

Search online for discussions about designing mobile apps to be accessible for those with disabilities and there’s only a smattering of recent, authoritative articles.

Even on college and university campuses, the issue of universal design of mobile apps remains an emerging area of focus by and large.

While the higher education community has made great strides with regard to the accessibility of educational materials and general technology, mobile apps have not yet caught up.

The Current Landscape
The Americans with Disabilities Act and Section 508 of the Rehabilitation Act of 1973 require federally funded institutions to ensure all individuals with disabilities can use online content as effectively as other individuals.

But when it comes to mobile apps and accessibility, there’s much work to be done.

A 2016 article in Digital Information Gazette points out that in terms of making information technology accessible to people with disabilities, websites have received the lion’s share of attention.

“The accessibility of mobile devices and apps is particularly pressing,” according to Dana Marlowe, principal partner at Accessibility Partners, “because of their rampant popularity.” Smartphones are everywhere, as are tablets. At the end of 2015, the Pew Research Center reported that 68% of Americans have smartphones and 45% have tablet computers.

“Mobile technology has sparked a new era of opportunity for people of all ages and abilities, yet many mobile apps have design flaws that prevent people with disabilities and the elderly from using them effectively,” stated IBM Chief Accessibility Officer Frances West in a press release issued by the company when recently releasing its own technology to identify and correct usability issues.

Accessibility in an App
Accessibility in app design can take a variety of approaches. Accessibility Partners recommends the following advice:

  • Accompany images and navigational controls such as buttons with text labels
  • Provide captioning with audio and video
  • Test your apps with assertive technology, including e text-to-speech tools

An Early Trailblazer
California State University, Northridge has been one of the early leaders in this arena. The school has made a concerted effort to ensure that all information technology resources and services are accessible to all students, regardless of disability. And that effort includes the school’s mobile properties.

What’s more, for the past three decades, the school has been hosting a one-of-a-kind conference on the subject – the CSUN Assistive Technology Conference.

Dedicated to presenting and exploring new ways technology can assist people with disabilities, the “CSUN Conference,” as it has become known, is the only one of its kind sponsored by a university.

“Disability is something that interferes with one or more major life activities. And ten to 15 percent of people meet that definition,” Cal State Northridge’s Kate Sharron pointed out during a talk on the subject at the 2016 Kurogo Higher Ed Mobile Conference.

A senior analyst for web services, Sharron helped launch the CSUN mobile app and spoke at the conference about the importance of universal design that is inclusive of mobile apps.

Some of her design suggestions for mobile apps included putting the app in grayscale, changing how touch works on the phone and also making text larger.

“Universal design will help you reach all students, meeting your students where they are,” added Sharron. “At CSU we take accessibility and universal design seriously.”

The Task Ahead

“Building accessible apps doesn’t have to be tremendously time consuming,” notes a mobile expert to Digital Innovation Gazzette. In fact, many devices have accessibility features available within the operating system.

By many accounts, a small amount of additional design and development time, over what is normally required, can result in a highly usable and accessible app.

In addition, remember to build accessibility into any refreshes, redesigns, or new rollouts of websites or mobile apps.

The big take away here is that universal design and accessibility should no longer be an afterthought or something that’s merely squeezed in during the testing phase.

“Factor accessibility in from the beginning,” urged Sharron at the Kurogo conference. “It shouldn’t be one of the last steps, it should be one of the first.”

When well planned and executed, assistive technology, even something as seemingly straightforward as a mobile app, can transform the lives of people with disabilities.


Reposted from 

WCAG 2.0 AA Gains Prominence as Website Accessibility Standard

The U.S. Architectural and Transportation Barriers Compliance Board (Access Board) finalized a regulation this week that will make the Web Content Accessibility Guidelines 2.0 (WCAG 2.0) Level AA the design standard when interpreting and implementing Section 508 of the Rehabilitation Act of 1973, which requires federal agencies and contractors to make their websites accessible to disabled individuals. Affected federal agencies and contractors will have one year from the publication of the final rule to comply with the revised 508 standards, which would place the compliance deadline sometime in early 2018.

The Access Board’s adoption of WCAG 2.0 Level AA strongly suggests that the U.S. Department of Justice (DOJ) will likewise adopt that standard when it finally issues its regulations. The process to issue its final regulations is not even projected to start until late 2018. As we have noted in the past, the DOJ and many courts have ruled that the Americans with Disabilities Act (ADA) requires accessibility for the websites of most private businesses even in the absence of DOJ regulations.

In the meantime, the DOJ and federal Department of Education’s Office of Civil Rights have also continued to reach private settlements with various parties that likewise make WCAG 2.0 Level AA the applicable standard for ADA compliance. The takeaway for private sector businesses looking to bring their websites into ADA compliance is that WCAG 2.0 Level AA has now gained further prominence as the most likely standard that a court will look to in determining a website’s compliance with the ADA.

© 2017, Ogletree, Deakins, Nash, Smoak & Stewart, P.C., All Rights Reserved.

Is your Website 508 Ready?

According to Google, 1 billion people in the world have disabilities – visually impaired & hearing disabled – who would benefit from an accessibility compliant web site. In addition, people who are not fluent in English, people who have trouble using a mouse, people with temporary disabilities, older people and new users can all benefit from adherence to web accessibility standards.

On January 18, 2017, the United States Access Board published a final rule that updates requirements for information and communication technology covered by Section 508 of the Rehabilitation Act and Section 255 of the Communication Act. To see if your company is at risk, visit the official website: – these new rules go into effect in 2018.

With the potential for increased market share, increased search engine performance, enhanced usability and the positive impact on brand reputation, your company can gain a competitive advantage. Combined with the reduced risk of class action suits, government fines, legal costs and the resulting PR loss, the case for making your web site accessibility compliant is compelling.


Reposted from Morgan Catlin’s blog

Differences between ARIA 1.0 and 1.1: Changes

Welcome to the third installment of SSB’s four-part review of the differences between ARIA 1.0 and 1.1. In the last post – Differences between ARIA 1.0 and 1.1: Additions to “role” – we explored the additions to “role”.  Today, we review the changes that were made to various attributes.

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.



The aria-owns attribute can be used to change the order of the accessibility tree, which is important when the DOM element structure of a widget does not match the correct parent-child relationship necessary to make such a structure work correctly. In such cases, the aria-owns attribute can be used to reference the IDs of the elements that are meant to be children of that container element.

The aria-owns attribute will cause the accessibility tree to be reordered, which will be recognized by assistive technologies that support the use of ARIA. In contrast, the use of the aria-owns attribute will not in any way reorder the element structure within the DOM, it only affects the order of the accessibility tree that is perceivable by assistive technologies.

The aria-owns attribute is a global attribute and may be added to any element. However, it is important to note that aria-owns must not be used on elements or roles that do not support children, such as HTML input elements or img elements. The same is true for combobox widgets that use role=”combobox” on an HTML input element, or any use of an HTML input+type=”text” or HTML textarea element, none of which should include the use of aria-owns. This is equally true for active elements such as links or buttons which should never include aria-owns to reference other active elements or container elements that include active elements.

The aria-owns attribute is often confused with the aria-controls attribute, though both are very different. The aria-controls attribute simply conveys an association between one or more elements that are controlled by the first, however, there is no parent-child relationship between these elements. Also, the use of aria-controls does not ever reorder the accessibility tree, only aria-owns can be used to reorder the accessibility tree.


In ARIA 1.0, the use of aria-activedescendant was defined as referencing the ID of a descendant child element to convey the child element as having focus in the accessibility tree, which required a parent child relationship in the accessibility tree according to spec.

In ARIA 1.1 however, the use of aria-activedescendant has been widened in scope to also allow for the referencing of any other element that is not a direct descendant of the focused element, meaning that aria-activedescendant can be used to convey that focus has moved to any other widget type regardless where that element actually is located in the DOM. The caveat being, that aria-activedescendant must point to an element that has an implicit or explicit widget role.

This change is especially important for interactive widgets such as autosuggest comboboxes, where the use of aria-activedescendant on the input control can allow the perceived focus in the accessibility tree to move into an associated Listbox control so that the up and down arrow keys can then change the highlighted option by dynamically updating the aria-activedescendant attribute on the HTML input field. This technique can also be used to traverse associated controls such as date pickers by referencing the date links using aria-activedescendant, which then controls the movement of the date picker using various keys all of which simply update the aria-activedescendant attribute on the focused input element. The same is true when using aria-activedescendant on an input to reference the various role=”treeitem” nodes within an ARIA Tree, so that the arrow keys when pressed will dynamically update the aria-activedescendantattribute on the input in order to convey that accessibility tree focus has moved into the tree even though literal DOM focus remains on the input element.

It’s important to note the difference between accessibility tree focus and literal DOM focus, which are not the same thing.

Literal DOM focus occurs when focus is set to a focusable element in the DOM, such as an active element like a link or form field. The accessibility tree focus however, is what is reported in the accessibility tree as currently having focus. To put this another way, the literal DOM focus reflects the currently focused element in the DOM, whereas the accessibility tree focus reflects only the accessibility tree object that is reported as presently having focus. In the DOM, only one element is allowed to have focus, which is also true in the accessibility tree, where only one accessibility tree object is allowed to be set as focused.

Assistive technologies like screen readers announce the accessibility tree object that has focus, not the DOM element that literally has focus. In practice, both the literal DOM focus and the accessibility tree focus always match, so that the element that has literal focus in the DOM is the same as the accessibility tree object that is announced to screen reader users as having focus.

The aria-activedescendant attribute however, can be used to override this automatic behavior in the browser and instead point to a different accessibility tree object to report as being focused, even though literal focus in the DOM has not moved.


In ARIA 1.0, the use of aria-haspopup could be either set to “true” or ““false”, and its only purpose was to convey the presence of an attached menu when set to “true”. The use of aria-haspopup was only valid when used for this purpose.

In ARIA 1.1 however, the use of aria-haspopup was extended to support a list of token values that can be used to fit a number of different circumstances. These include all of the following:

  • false (default) = Indicates the element does not have a popup
  • true = Indicates the popup is a menu
  • menu = Indicates the popup is a menu
  • listbox = Indicates the popup is a listbox
  • tree = Indicates the popup is a tree
  • grid = Indicates the popup is a grid
  • dialog = Indicates the popup is a dialog

Also, in ARIA 1.0, the aria-haspopup attribute was not specifically called out as needing to be placed on a focusable keyboard accessible element, however this has been tightened up in 1.1 where it now specifies that the use of aria-haspopup should be placed on a keyboard accessible element where it can be triggered properly.

It’s important to note that none of the token values are supported within browsers or assistive technologies as yet, and likely won’t until the end of 2017 at the earliest.


In both ARIA 1.0 and 1.1, role=”form” is declared as a landmark. However, the assistive technology mappings were changed in 1.1 to cause role=”form” to behave as a landmark, whereas before they did not. This also impacts the implicit role mappings for the HTML form element, which historically do not map to the ARIA form role as expected.

This lack of implicit role mapping for the HTML form element is intended, however, because if it were otherwise, all form elements would be declared as landmarks on all web pages, which would be extremely confusing and non-intuitive. So a compromise was reached, where an HTML form element will only be mapped to the ARIA form landmark role if it includes an explicit name using either aria-labelledby or aria-label. Otherwise, the HTML form element will not be mapped to the ARIA form role as a landmark.

One more to go!

This is the third of a four-part series on the Differences between ARIA 1.0 and 1.1. Please click here for part one and part two. In the next installment, I’ll delve into role=”combobox”. It’s a bit complicated, so it deserves its own post.

‘Hamilton’ Sued for Not Accommodating Blind Patrons

The Broadway hit and multi-Tony winner Hamilton is now the subject of a class action lawsuit involving alleged violations of the Americans With Disabilities Act.

Mark Lasser has sued producers of the show, claiming Hamilton is denying blind and visually impaired fans equal access to performances across the U.S. because the show doesn’t offer audio description technology. The service provides patrons with a small receiver that connects to headphones and plays audio narration that describes visual elements of the scenes.

“Many individuals who are blind or visually-impaired enjoy watching musicals in theatres and engaging in this classic part of American cultural life,” writes attorney C.K. Lee in the complaint. “Audio description technology is essential to the live musical experience for blind individuals, so that they will know what is happening in scenes without dialogue or scenes that include significant visual elements.”

Lasser says he contacted the box office at the Richard Rodgers Theatre in New York to inquire about services for the blind and visually impaired and was told none were available. He also claims he tried to resolve the issue without a lawsuit but producers were not responsive.

Nederlander Organization, which owns the theater Lasser contacted; the show’s producer, Hamilton Uptown LLC; and its manager, Baseline Theatrical LLC, are named as defendants in the lawsuit. None of the companies have responded to a request for comment in response to the suit.

Lasser is asking the court to order defendants to provide audio description equipment and live narration services once each week with 25 audio sets available for the show.

Court Orders Company to Make Website Accessible to the Blind

A California blind man has won a disabled-rights case against a Colorado-based luggage retailer accused of failing to make its commercial website accessible to the visually impaired.

Lawyers for the plaintiff said the ruling broke new ground in an expanding litigation area.

Edward Davis last year sued Colorado Bag’n Baggage in California court claiming he couldn’t shop online for the retailer’s products because its website lacked features, like screen-reading software, for aiding the disabled. The suit claimed violations of the federal Americans with Disabilities Act and a California anti-discrimination law.

Before any trial, the judge this week ruled for the plaintiff. Mr. Davis “presented sufficient evidence that he was denied full and equal enjoyment of the goods, services, privileges, and accommodations offered by Defendant because of his disability,” wrote Judge Bryan F. Foster of San Bernardino Superior Court.

He ordered the retailer to make changes to its website and to pay $4,000. Lawyers for Mr. Davis are also entitled to attorneys’ fees, which they expect to exceed $100,000.

The lead counsel for the plaintiff told Law Blog that the ruling marked the first time in such a lawsuit that a court has entered a judgment in favor of a plaintiff over a defendant’s objections. “It’s pretty groundbreaking,” said Scott Ferrell, founding partner of litigation boutique Newport Trial Group.

Law Blog has sought comment from an attorney representing the retailer.

Such disability-rights cases have grown more common in the last couple of years.

As WSJ has reported, litigation in the area picked up steam in 2014 when the Department of Justice laid out a set of compliance standards for accessibility on commercial websites as part of a legal agreement with H&R Block Inc. in a case originally brought by the National Federation of the Blind.

Another turning point came in 2008 in a case against retailer Target Corp. when a federal district judge ruled that ADA applies to websites when they act as a gateway to a brick-and-mortar store. That case resulted in a $6 million settlement.

Crystal N. Skelton, a California attorney who advises clients in complying with disability laws, says companies can expect these lawsuits to continue.

“If you aren’t sure whether the ADA applies to your site or whether it’s accessible to the blind, now may be the time to find out,” she and a firm colleague wrote in a blog post about the case.

Section 508 Final Rule 2017 Refresh

On January 18, 2017 United States Access Board has released an update for the final rule on standards for electronic and information technology developed, procured, maintained, or used by Federal agencies covered by section 508 of the Rehabilitation Act of 1973, as well as the guidelines for telecommunications equipment and customer premises equipment covered by Section 255 of the Communications Act of 1934. The Section 508 standards and Section 255 guidelines refresh are intended to ensure that information and communication technology covered by the respective statutes is accessible to and usable by individuals with disabilities. The Revised 508 Standards and 255 Guidelines replace the current product-based regulatory approach with an approach based on ICT functions.

Highlights of section 508 final rule

  1. New Regulatory Approach and Format
  2. Broad Application of Web Content Accessibility Guidelines 2.0
  3. Harmonization With International Standards
  4. Delineation of Covered Electronic ‘‘Content
  5. Expanded Interoperability Requirements
  6. Extended Compliance Date and Incorporation of Safe Harbor Provision for Section 508-Covered Legacy ICT

Section 508 final rule key Dates

  • The Section 508 final rule is effective from March 20, 2017. This means All ICT that is published on or after March 20, 2017 must be compliant as per the new Section 508 standards.
  • ICT that is published before March 20, 2017 must be still compliant as per old Section 508 standards.
  • Compliance with the section 508-based standards is not required until January 18, 2018.
  • Compliance with the section 255-based guidelines is not required until the guidelines are adopted by the Federal Communications Commission.

Related links

Reposted from Rakesh Paladugula

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