Innovations in Web Accessibility:
Reviewing the Last Decade and Identifying Transformative Opportunities
- To identify significant innovations in Web accessibility which
have arisen during the last decade.
- To explain the problem that each innovation addresses, in its
proper historical context.
- To outline the solution offered.
- To indicate further research opportunities that the solution
suggests, e.g., extensions of the technique to address as yet
- The innovations described here are not exhaustive, but each of
them constitutes, in my view, a fundamental advance in Web
- Some of these innovations consist in the application to the Web
of design strategies used successfully elsewhere, for example to make
graphical user interfaces accessible to users of assistive
- Other innovations, such as personal needs and preferences
profiles, are new ideas that depart from the paradigm of making a
single user interface accessible to all.
- Standards for Web accessibility are now starting to be applied
see Guidance on Applying
WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT).
Research and Standardization
- The Web is defined by technical standards.
- Innovative research into Web accessibility tends to be
introduced into new standards, or revisions of existing standards.
- Innovation occurs in academic or industrial research
facilities, non-profit organizations and collaborative efforts
within standards bodies themselves, for example W3C working groups.
- W3C standards continue to play a leading role in the development
of new Web-based technologies for improving accessibility.
- Much innovation in Web accessibility in recent years has
responded to the growing needs of educational applications in particular.
The Challenge of Educational Contexts
- Courses and assessment can be delivered online.
- User interfaces may exhibit all the complexity of modern Web
- Examples: messages, online chat, collaboration tools, as well as
the course materials themselves.
- Multimedia may be used extensively.
- The content may be complex: mathematical notation, diagrams,
multiple languages, music notation, phonetic transcription (in linguistics
courses), chemical equations, etc.
- It may be interactive, e.g., simulations, exercises and tests.
- Summary: educational applications present complex challenges for
accessibility that rarely occur elsewhere.
Accessible Rich Internet Applications (ARIA): Characterizing the
- ARIA is one of the most successful accessibility-related
innovations of the last decade.
- It was designed to solve two main problems.
- Dynamic HTML
- The need for improved navigation.
Problem: Dynamic HTML
- User interface components not available in HTML can be
element, an application author may prefer styling or behaviour that
is best achieved by writing a custom user interface control.
- These components are not represented by standard HTML elements such as
- Instead, authors often use general-purpose elements such
A Problem for Assistive Technologies: Accessibility APIs
- Many assistive technologies rely on accessibility APIs.
- A Web browser provides information about the structure and
content of a Web page to an assistive technology (e.g., screen
reader, screen magnifier).
- This is accomplished via an accessibility API supplied by each
underlying operating system.
- The API presents a tree of objects (the desktop, windows, an HTML
document, headings, paragraphs, table cells, lists, links, form
- A screen reader can then present these to the user and respond
appropriately to changes in the UI as the user interacts with it.
standard HTML elements with their intended meanings, and changes
occur in the document as author-supplied scripts responds to the
user's actions to give effect to the behaviour of custom UI controls.
- Therefore, the browser can't forward the necessary information to
an AT via the accessibility API.
Solution: Adding ARIA attributes to the Document
- Add a
role attribute to classify the custom control.
- Forward this role information to the accessibility API of the
operating system, and hence to assistive technologies such as screen readers.
- Many roles are predefined in ARIA.
See Accessible Rich
Internet Applications (WAI-ARIA) 1.0.
- Add attributes to convey the state of the custom control (e.g., whether
a checkbox is checked).
for example, when
the user changes the state of the checkbox from unchecked to checked.
- When state changes occur, assistive technologies are notified via
the accessibility API, and can then inform the user of the change, as appropriate.
- Focus handling and keyboard access must be implemented by the
custom component for the
benefit of screen reader users.
1.0 Authoring Practices.
A Simple HTML Example
A two-state checkbox, as it could appear in an application, may be represented in HTML and ARIA as
<span role="checkbox" aria-checked="false" tabindex="0">
<img src="unchecked.png" role="presentation">Simple checkbox</span>
- Initially, this checkbox is unchecked. When this state is
changed by the user,
a script must update the visual check mark (the image referred to
above), and change
notify the AT.
- The image is entirely presentational, and designated as such by
presentation ARIA role.
tabindex attribute ensures that the checkbox
appears in the navigation sequence and can receive focus via keyboard
Problem: inadequate navigation
- Screen readers and speech-enabled browsers allow the user to
read and traverse the structural components of a Web page or application.
- HTML can represent headings, paragraphs, lists, tables,
quotations and other document structures.
- A modern Web page or application may also include a navigational menu,
a main content area, a document being edited, a search tool, and
- These components aren't expressible in standard HTML elements
(prior to HTML 5).
- Screen reader users often wish to jump to these key items
quickly, but unless they are identifiable via the accessibility API,
the assistive technology can't identify them so as to support such navigation.
Solution: Structural and Landmark ARIA Roles
- Add ARIA roles to identify key components of the
- Disclose these roles in the accessibility API to assistive
Scope for Extensions
- ARIA is designed to be supported by any host markup language,
not just HTML.
- Adding ARIA to Scalable Vector Graphics (SVG).
- SVG: an XML-based language for describing images in terms of shapes, paths,
etc., rather than as collections of pixels.
- ARIA attributes can be added to SVG documents (currently subject
to standardization efforts -
2, section 5.11, working draft).
- This should enable highly graphical and dynamic user interfaces
written in SVG to be made accessible.
- In the future, ARIA could be extended to describe components of
diagrams represented in SVG.
- Example: ARIA attributes could be defined so as to make directed
and undirected graphs accessible to screen reader users.
- In HTML 5, there are new elements that make it unnecessary to use
certain ARIA roles explicitly.
range input fields in forms.
- This trend can be expected to continue.
Using the Tools of the Web to Implement Assistive
- In a typical browser (e.g., Mozilla, WebKit), an internal,
abstract accessibility API is implemented.
- This is mapped to the accessibility API of each supported
- The user interface is then constructed by an assistive
technology, which interrogates the Web browser via the accessibility
- Enhancing the information that can be provided to the AT, for
example to support new ARIA roles, requires changes to the browser,
and potentially also the accessibility APIs of multiple operating
systems as well as multiple assistive technologies.
- All of the coordination which this entails impedes innovation.
- Furthermore, the alternate user interface is constructed by the AT
separately from the browser and its styling mechanisms.
Solution: Implementing the AT as a Browser Extension
- This design was first developed by T.V. Raman for Emacspeak.
- He terms it the "speech-enabling" approach.
- It presupposes an extensible platform (e.g., Emacs, a modern Web
browser) in which applications are written.
- It requires functions to be introduced which are called at
appropriate times to generate speech output and to respond to the
- In the Web environment, this is achieved by "injecting" scripts
into Web pages that add support for speech interaction.
- The text to speech facility is supported by the browser itself,
and the assistive technology is written as a browser extension.
- The AT has direct access to
browser APIs and the Web page itself.
- It can control the speech output directly.
- Custom scripts can be written to make Web applications more
accessible, for example by modifying the underlying Web page to
improve navigation for the user.
- Operating system-level accessibility APIs are bypassed,
facilitating rapid innovation.
Example: Support for Mathematics
- Support for mathematics (MathML) is being added to ChromeVox.
- There is no need to wait for accessibility APIs under different
operating systems to be extended.
- Innovation in the assistive technology can occur much more
- The AT is written in a widely understood scripting language, not
requiring system-level changes, and therefore it can be more easily customized.
- Bringing speech recognition into the browser.
- Adding support for braille displays.
- Implementing other assistive technologies as browser
- Rapidly supporting new accessibility-related innovations, such as
- Using speech style sheets to improve the speech output by setting
voice properties (announcement of punctuation, pausing, auditory
icons, pitch, speech rate, etc.).
- The electronic publishing community is interested in the CSS
Speech Module for use in educational applications such as textbooks.
- Challenge: how to coordinate and integrate an assistive
technology written as a browser extensions with operating
system-level AT software that the user may also be running.
Individualized Accessibility: Sample Scenarios
- A user wishes to find resources (e.g., using a search engine)
that meet her or his accessibility needs.
- Example: a student undertaking an online course needs to select
relevant exercises that are compatible with his or her assistive technology.
- Example: a user needs instructional videos that provide
captions, preferably in a specified sign language (for example,
American Sign Language, Australian Sign Language).
- Some users may require custom interfaces that are not best for everyone.
- Example: a user with a particular cognitive disability needs the
navigational components of a Web site to be simplified by presenting
a maximum of, for instance, four links simultaneously.
Generalizing the Problems
- Disclosing the user's accessibility requirements to Web
applications so that user interfaces can be adapted appropriately.
- Automatically ascertaining the accessibility-related capabilities
of Web resources.
Solution: Personal Needs and Preferences Profiles, Metadata
- Create a profile of the user's individual needs and preferences.
- Example: the user requires captions (preferably in a sign
- Disclose this profile to Web applications, e.g., online course
management systems. This can be achieved with metadata or via an API
available to Web applications.
- Add metadata to Web resources that declare the
accessibility-related needs and preferences which they support
(for example, by asserting that a video provides captions).
- Metadata associated with Web resources can be read by search
engines, learning management systems or other applications.
- A Web application can be written so that it adjusts its user
interface according to the expressed needs and preferences of the
- The course management system offers the student only appropriate
exercises compatible with her or his AT.
- Compatibility is determined by matching the student's expressed
need with metadata describing the accessibility-related features of
- The video search engine confines its search results to videos
that match the user's caption requirement.
- Alternatively, such videos are ranked highest among the search
- This is accomplished by matching metadata associated with the videos with
the user's personal needs and preferences.
- The Web application supports the needs of the user with a
cognitive disability by organizing its user interface to present a
maximum of four items simultaneously, and by clarifying the user's
current position in the navigational hierarchy.
- To achieve this, it responds to the user's personal needs and
preferences profile by presenting an appropriate interface that
facilitates comprehension and interaction based on the individual's
Standards that Support Needs/Preferences Profiles and Metadata
- IMS Global Learning Consortium, Access For All specification
Specifications for version 2 and a draft of the extensively
revised model in version 3.
- Also available as an ISO standard (ISO 24751).
- Developed for use in learning management systems.
- This standard specifies both a Personal Needs and Preferences
Profile, and a Digital Resource Description (metadata for specifying
the accessibility-related capabilities of Web resources).
- Global Public Inclusive Infrastructure (GPII): implementing personal needs and
preferences profiles in operating systems.
- schema.org: defining accessibility-relevant metadata for use by
Web search engines. (See
the proposed specification).
- This is also of interest to the educational community, for
example to help users locate digital books that are accessible to them.
IndieUI User Contexts Specification
- This standard is under development by the W3C's Independent User
Interface (IndieUI) working group.
- It aims to bring personal needs and preferences profiles into
the browser directly.
- It will provide an API to access the needs/preferences, while
addressing privacy concerns.
- An early draft has been written; requirements are still being
- The first public working draft has not been published yet.
- The relationship with CSS Media Queries is subject to further
investigation and discussion.
- The relationship with accessibility-related metadata standards
for describing Web resources is also recognized as important in the
- The potential of this technology to meet the needs of people
with cognitive, language and learning disabilities remains to be
- This may be investigated further in current efforts to identify
strategies for making the Web more accessible to people with
- Some techniques for improving access may not be appropriate for all users, but may be
required to satisfy the needs of specific users.
- In these cases, personalized accessibility can address everyone's
- Strategies for designing Web applications with user interfaces
that adapt to the individual's expressed needs, remain to be
Preference Discovery and Metadata Collection
Recent research has started to explore:
- How to design preference discovery tools to obtain accessibility
needs/preferences from users.
- How to achieve this when the user's preferred language, input
method and output modality are not known in advance.
- How to infer accessibility-relevant metadata about Web resources
from patterns of interaction, user ratings and recommendations,
thereby avoiding manual creation of metadata.
for Global Access: Profile Creation Support for Cloud-Based Accessibility.
The Rapid Development of Mobile Devices
- Mobile devices (tablets and phones) have developed rapidly in
recent years, in respect of both hardware and software.
- Speech synthesis and speech recognition, for example, are
increasingly used in mobile applications.
- Examples: voice commands, satellite navigation applications.
- Touch gestures have become an increasingly important input
method, with the growing adoption of multi-touch displays.
Convergence of Interest: Mobile Devices and Accessibility
- That users of mobile devices and users with disabilities often
have common needs has long been recognized by standards developers.
- The Web Content Accessibility Guidelines have been cited as
valuable advice for the implementation of mobile Web applications.
- Issues formerly of concern only to those interested in
accessibility now have a wider audience.
The Need for Abstract Input Events
- It no longer suffices for Web applications to support only
mouse/pointer events and keyboard events.
- There is now a need for touch input support, and interest in
speech input can be expected to grow.
- Currently, in many cases, Web application authors need to
handle touch, mouse and keyboard events separately to perform the
same underlying actions.
- Events are identified at a low, device-specific level.
- Too much work is required of authors, and inconsistencies can
Current Specifications and Guidelines
Solution: IndieUI Events
- The need for better input handling for purposes of both mobile
devices and accessibility led to an effort by the W3C to develop a
Events 1.0 (work in progress) defines abstract events which are
independent of specific hardware devices.
- An abstract event can be invoked by any device supported for
this purpose by the user agent.
- Examples: mouse actions, touch gestures, speech input, keyboard
input, commands forwarded by assistive technology.
Examples of Abstract Input Events
There are events for
Moving or resizing an object on a canvas,
- Changing the value of a user interface control (e.g., a
- Undoing and redoing an action (for example, in a text editor),
- Scrolling the viewport,
- Expanding and collapsing hierarchical UI controls such as tree
- Moving focus directionally, when the entire document is not
loaded into the browser by the application,
- Controlling audio and video players.
These are non-exhaustive examples.
- Document navigation (where the entire document is not loaded
into the browser at once for performance reasons),
- Navigation to ARIA landmarks (see above for a discussion of
ARIA landmark roles),
- Selecting objects, then performing an action on them (often
presented visually as drag/drop interaction).
The Importance of Convergence
- Technologies of interest to multiple constituencies are likely
to achieve greater adoption.
- Mobile and accessibility, for instance, have a clearly
Toward Greater User Interface Abstraction?
- The demands of multiple devices and multiple modalities are
- Note the debate surrounding attempts to make operating system
user interfaces that are suitable for both mobile and desktop
- The needs of increasingly diverse devices and users may lead to
more abstract mechanisms for specifying and associating
style/behaviour with user interfaces.
- Research motivated by requirements for accessibility has already opened the way to such interfaces.
- Example: Universal Remote
- Designers of new technologies should seek to generalize the
solutions they offer and to address a variety of usage scenarios
(including those arising from the needs of people with
- Accessibility can best be served by building technologies that
support it at the outset.
- The costs and difficulties of making an already established
technology accessible are considerable, and avoidable.
- Moreover, technological change intended to increase accessibility
can have large and wide-ranging benefits, for instance to users of
mobile devices, as already discussed.
- Web accessibility has made substantial technological progress in
recent years, but much research remains to be done in order to
support the complexities of modern Web applications, especially in