Month: January 2017

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.

Changes

aria-owns

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.

aria-activedescendant

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.

aria-haspopup

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.

role=”form”

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.

Advertisement

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

http://blogs.wsj.com/law/2016/03/25/court-orders-company-to-make-website-accessible-to-the-blind/?mod=WSJBlog

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.

role=term

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.

role=figure

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.

role=feed

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.

role=searchbox

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.

role=switch

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.

role=none

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.

Deprecations

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.

Additions

aria-keyshortcuts

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.

aria-roledescription

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.

aria-modal

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.

aria-errormessage

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.

aria-placeholder

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.

aria-current

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.

aria-details

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.

U.S. Access Board

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

3:29 PM – 5 Jan 2017

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.

SECTION 508 GETS ICT UPGRADE TO MATCH WCAG LEVEL A & AA STANDARDS

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