Accessibility Problems with Web Applications
Internet user interface components and seamless page updates by scripts provide richer experiences for users. Unfortunately, this
results in accessibility problems for users of assistive technologies and users who can not use a mouse when the ARIA specification is not followed. Accessibility is hindered because screen readers
can not ascertain and convey what dynamic changes or updates have been made without the ARIA spec.
Before the ARIA spec
- Web Component/Widgets are rarely keyboard accessible.
- The role of the widget and its function is not available to assistive
technology.
- States and properties of the component/widget app are not available to assistive
technology.
- Updates, and discovery of the updates are not reported to assistive
technology.
- Custom widgets are dependent on stylesheets to position their elements with or without ARIA. Therefore, without stylesheets, these widgets disintegrate and are no longer usable.
WAI-ARIA to the Rescue
Fortunately, these problems are solved by the Web
Accessibility Initiative’s Accessible Rich Internet Applications
(WAI-ARIA) specification. ARIA landmark roles assist users of assistive technologies (AT) when
navigating web pages by describing the type or purpose of content. The accessibility community has welcomed the development of WAI-ARIA.
Clearly, there are many benefits for screen reader users. Now, WAI-ARIA can inform the screen reader about dynamic Web page changes.
Instead of having to tab through or listen to each section of a page,
such as a banner, and footer, or to find out what it is about,
ARIA landmarks allow all users to navigate directly to the desired section. And ARIA allows developers to create accessible rich Web applications that are easy to implement.
Since HTML 4 has no explicit elements for marking up page regions,
the WAI-ARIA spec offers document landmarks. For example, a
div can be marked up with role="navigation" and expose the main page content with role="main". This
allows screen reader users that support WAI-ARIA to move with ease between
the different page regions.
Other ARIA attributes improve form markup: For example, input elements can be given the attribute aria-required="true" to inform
screen reader users that the field requires an entry before the form can be submitted.
Is the ARIA spec available now?
Yes, IE, Opera, WebKit, and Firefox all support the expanded tabindex
feature. Therefore, whether you use that format or style the focus yourself, the component/widget applications will be keyboard accessible in every
major browser.
The W3C addresses dynamic Web content and Web applications developed with
Ajax, DHTML, and other Web technologiess and gives guidelines for making them into accessible rich internet applications/ARIA.
See ARIA terms.
The W3C Web Accessibility Initiative Suite explains how to make Web content and Web applications
more accessible to people with disabilities. Currently certain functionality used in
Web sites is not available to some users with disabilities, especially people
who rely on screen readers and people who cannot use a mouse. The WAI-ARIA offers accessibile solutions by defining new ways for functionality
to be provided to assistive technology. With WAI-ARIA, developers can make advanced
Web applications accessible and usable to people with disabilities. IE:Assistive technology accessibility is enhanced by ARIA Landmark Roles.
ARIA and browsers
Does ARIA break Web pages on current browsers? No, ARIA role and property information only affect how the page
interacts with assistive technologies. It does not affect how mainstream users interact with the page. It also does not affect how the
page works on legacy browsers. It only changes accessibility for
inaccessible component/widget applications.
ARIA and Screen Readers
With ARIA, screen readers switch to the "application mode".
Application mode is still a relatively new concept. When
JAWS says "application mode", this informs AT users to expect an
interface with similar interaction to a desktop application, rather than
a traditional Web page. This mode is definitely an improvement
for complex, dynamic web application interfaces that simply would not
work when navigated in virtual mode. Virtual mode would not be
sufficient here because the interaction on such
interfaces depends largely on keyboard interaction.
Screen Reader modes
- PC Cursor Mode:The user receives the same screen reader support as in a desktop
application, which means no link lists or Web page specific screen reader shortcuts are available as used in the PC virtual cursor mode.
As in desktop applications, it is the developer's
responsibility to ensure that the Web interface is fully keyboard and
screen reader accessible.
The application role should only be used when
the web application has been built with accessibility in mind and
tested for it.
- Documentation should be provided about how the user-interface operates as well as descriptive hints about the specific component.
IE:Right arrow key needs to be used to add an item to the queue.
Standardized keyboard interface shortcuts have been developed. See shortcut
examples.
Planning accessibility from the beginning with Web applications
Developer accessibility resources and tools
