Building a WCAG2 Compliant Site with ARIA
Thomas M. Logan
Abstract – The Web Accessibility Initiative Accessible
Rich Internet Applications (ARIA) specification is nearing
completion [1]. Any nascent web standard will struggle withinconsistent implementations. Consistent and accurate
documentation of best practices is critical in ensuring that anew format becomes adopted broadly and consistently. This
paper explores the developer perspective of creating anaccessible web application. Accessibility APIs have failed
in the past because of the lack of documentation and clear
guidelines. Real world examples have been requested fromdevelopers across all fields to understand how accessibility
is supported.
In general, accessibility issues with rich internet applications
can be characterized as:• Providing the semantic structure of page areas andfunctionality (e.g., navigation, main content, search,etc.)• Allowing certain non-focusable page elements toreceive keyboard focus (e.g., setting focus to anerror message within the page)• Providing keyboard and screen reader accessibility
with complex widgets and navigation elements(e.g., sliders, menu trees, etc.)• Maintaining accessibility of content that is dynamicand may change within the page (e.g., AJAXcontent updates)
ARIA provides solutions to each of these problems. It allows
developers to specify a role for page areas and elements,
such as navigation, main content, and search. This allows
quick access directly to these page areas. In web content,
typically only links and form elements can receive keyboard
focus or will allow keyboard interactivity. With ARIA, theauthor can allow any page element to become interactivewith the keyboard. This allows greater levels of accessibility
and interactivity for keyboard and screen reader users. The
developer can specify if and how intrusive the notification
for user will be when these areas are updated. ARIA
provides accessibility support for dynamic, complex pagewidgets (interactive controls). Finally, ARIA also allows thecreation of live regions, special areas of the page that can be
updated dynamically.
I. PAGE STRUCTURE
Proper structure of HTML content is essential in ensuring
efficient navigation of large amounts of content. Section
508 contains a requirement for skip navigation links to allow
a keyboard user to jump to the main content of the page [1].
The skip navigation requirement is an important
accommodation for allowing a user to skip to the mostimportant area of the page. There are many new web design
patterns that benefit from providing quick access toadditional common areas on the page. Developers of web
content need to begin with thinking about what logicalblocks of information exist on the page. Most commercial
pages have a banner along the top that contains the logo.
This can be identified by setting the ARIA role attribute to“banner”. The main content should be contained within adiv element that has the role attribute set to “main”. This
will enable an assistive technology to quickly jump to thislocation on the page. This will also allow the requirement ofplacing a skip navigation link on the page to be removed.
It is also important to note that more than one instance ofa type of landmark role can be used on a page. The ability to
tag multiple navigation bars on an application is a perfect
example. One common design pattern is to have a top
navigation bar and a left navigation bar. Marking thiscontent up with ARIA will allow an assistive technology toefficiently jump between the two or more navigation regions
on the page. Tagging the footer content of a page will
enable it to be deconstructed from the presentation of thepage. When using any of these roles, a strong visual bordershould be used to outline the content to assist inunderstanding the structure of the page through visualcomprehension. Each region must have a proper headingthat is identifiable for the content and unique.
II. KEYBOARD SUPPORTKeyboard support is of increased importance to the web
as more complicated UI behaviors have become available.
The original interfaces of the web are largely a point andclick pattern. A user navigating a page with the TAB andENTER key could effectively access everything. This is one
reason that initial Section 508 requirements for the web did
not include keyboard requirements [1]. Now that web
components can be built from many different subcomponents it is more difficult to enforce a uniform
keyboard model.
It is best to follow a standard
recommendation so that users will know how to interact witha particular piece of the user interface. A web application
developer should work through their application using only
the keyboard. This will illuminate the areas that needadditional work from the keyboard. When deciding what
keystroke should correspond with a particular action, thedeveloper should follow the guidelines at the DHTML Style
Guide to ensure a standard experience [3].
Web development projects now require the ability todifferentiate between web content and web applications. A
web application will require a comparable keyboard model
to its desktop application counterpart.
Assistive
technologies are able to customize their commanding models

when finding the role attribute set to “application” on thebody element of a web application.
Web developers can support accessibility best practices
by choosing to use web controls from component developersthat have implementations for ARIA and keyboard access.
This saves developers a large amount of work and ensuresthat good accessibility support is rewarded.

the song that the video player is currently playing. If thisnotification was announced to a reader every time it updated
on the screen, there would be no opportunity to hear any
other content. In these cases the web author should mark theregion with the aria-live attribute set to”off”. Reader
technologies may still access and present the value of thetimer through navigation of the browser’s Document Object
Model.

III. ROLE AND STATE INFORMATION
V. CONCLUSION
Providing role and state information about a component
is covered in the Web Content Accessibility Guidelines
under Guideline 4.2, “For all user interface components(including but not limited to: form elements, links andcomponents generated by scripts), the name and role can beprogrammatically determined; states, properties, and values
that can be set by the user can be programmatically set; andnotification of changes to these items is available to useragents, including assistive technologies[4].” These role andstate requirements in WCAG2 can be met throughsupporting various ARIA attributes on elements. These
requirements are difficult to comprehend due to every typeof control requiring different specific pieces of information
to be present. When the information is made available it isimportant to test with that a set of assistive technologies will
be able to interpret it.
Automation plays an important role in ensuring
compliance with a specification that contains as manyrequirements as ARIA does. By having automated test
cases, a more complicated specification can have stronger
adherence. Often authors strive to make their site as
accessible as possible but find it difficult to interpret the vastrequirements that exist in accessibility specifications.
Without automated enforcement checks, bad coding
practices become standard across applications. If assistive
technologies need to enact specific workarounds to enable aparticular application, other application authors will have toincorrectly implement a specification to function.
IV. LIVE REGIONSLive regions address the dynamic nature of modern web
applications. A live region can be used to notify a screen
reader that a specific update on the screen is important to beread. It can also be used to tell a reader not to automaticallyannounce a particular update on the screen. It is fair to saythat the majority of current web sites have areas where live
regions can be made use of. Developers need the ability toprovide a notification to a user that a particular action has
successfully occurred. For example in the Queue Music[5]application, the author wishes to notify a user that a
particular song is loading after the user presses enter torequest an item to play. This can be achieved through using
the aria-live attribute to mark the dynamic region thatcontains the status of the player.
In the Queue Music application, there is also a piece ofcontent that should not be read automatically to the user.
There is a timer value that indicates the current position in

A common assumption of web developers in 2009 is thatuse of advanced JavaScript coding techniques is forbidden.
With ARIA this assumption is fortunately no longer valid.
ARIA techniques enable most web content to be madeaccessible. The challenge will be ensuring that bestpractices are enforced through documentation andautomation. Good implementations of ARIA must be
available through commonly used assistive technologies toensure wide adoption of ARIA. For a company or institution
to use ARIA they need to be able to see the solution working
end-to-end with an assistive technology. Coordinated efforts
are ongoing in 2009 between assistive technologies,
corporations, and tool vendors to ensure that content bestpractices work reliably.

REFERENCES
[1]
[2]

[3]
[4]
[5]

Accessible Rich Internet Application (ARIA) 1.0. 18 May 2009.
W3C. 18 June 2009 <http://www.w3.org/WAI/PF/aria/>.
Section 508: Section 508 Standards. Access Board. 18 June 2009<http://section508.gov/index.cfm?FuseAction=Content&ID=12#Web>.
DHTML Style Guide. 13 May 2009. AOL LLC. 22 June 2009<http://dev.aol.com/dhtml_style_guide>.
Web Content Accessibility Guidelines (WCAG) 2.0. 11 Dec. 2008.
W3C. 18 June 2009 <http://www.w3.org/TR/WCAG20/>.
Queue Music. 1 May 2009. Thomas Logan. 22 June 2009<http://www.queuemusic.org>.