The Web is fundamentally designed to work for all people, whatever their hardware,
software, language, culture, location, or physical or mental ability. When the Web
meets this goal, it is accessible to people with a diverse range of hearing, movement,
sight, and cognitive ability.
W3C Accessibility Basics
W3C Accessibility Basics
This is how the
World Wide Web Consortium Accessibility Basics article starts. To help make
the web more accessible, W3C maintains the
WAI-ARIA specification. In a world of ever advancing web technologies, the
and CSS is used to create UI experiences that go far beyond HTMLs inherently document-oriented
nature. WAI-ARIA tries to fill in the semantic gap between HTML as a language that
describes content and the increasingly control-oriented tools and widgets it is
used for. The justification is obvious - accessibility tools and assistive technologies
understand HTML, but HTML's semantic structures by themselves are not enough to
describe complex visual entities and specific functionality associated with them.
To enhance the semantic power of HTML, WAI-ARIA defines a set of roles that correspond to various
on your page. These widgets are characterized by various states and properties. Roles, states and properties are
implemented as attributes of elements in HTML. Web content authors
are responsible for specifying semantically correct roles for various widgets, sections,
menus, and other functionally rich parts of the page. Together with that, interactive
content needs to be described through WAI-ARIA states and properties, so that assistive
technlogies can identify and describe available operations and expected outcome
to the user.
There is more to accessibility that can be said in a single blog post. A single
blog post, however, will suffice to introduce you to the accessibility improvements
we have introduced in RadControls for ASP.NET AJAX, and more specificially, WAI-ARIA
support. With the upcoming Q2 2011 beta release, 9 controls from the ASP.NET AJAX
suite support WAI-ARIA: RadTreeView, RadGrid, RadEditor, RadTreeList, RadCalendar,
RadInput, RadWindow, RadTooltip and the newly introduced RadNotification. They all
share a common property - EnableAriaSupport.
Let's take RadGrid:
Without WAI-ARIA support, the rendered markup would be like:
When we set EnableAriaSupport="true", RadGrid renders the following
Note how the grid markup is decorated with role and aria-[state]
attributes. These describe the functional parts of the grid to assistive technologies.
Additionally, a grid may not stay in the form it has been originally rendered. When
you enable selection, for example, RadGrid updates the selected state of rows with
the aria-selected attribute:
Similarly, when grouping is used, group headers get the role="rowgroup"
attribute and depending on whether they are expanded or not, the aria-expanded
attribute is set:
Similarly to RadGrid, we have taken the care to thoroughly describe the semantics
of all WAI-ARIA-enabled components. If you want to find out more about this feature,
wait for the Q2 2011 beta release (expected by the end of the week) and give it
a try yourself. Let us know how this can be of use in your accessible projects,
and definitely share an opinion if you believe more can be added or we can further
Veli Pehlivanov is a Technical Lead at one of Telerik’s ASP.NET AJAX teams, where he primarily
works on RadGrid and a few other data- and input-centric controls, including RadListView,
RadCalendar and RadInput. Veli's interests lie in the area of web development, C#,
of technology and is keen on delivering efficient software and a greater value for
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.