WebAIM - Web Accessibility In Mind

E-mail List Archives

Static vs. Interactive Widget Roles - Ensuring Proper Functionality in ARIA

for

From: Bryan Garaventa
Date: Mar 6, 2017 1:29PM


Hello,
For those who were not able to attend CSUN this year and missed this session, the presentation printout has been published at
https://www.linkedin.com/pulse/csun-2017-printout-static-vs-interactive-widget-roles-bryan-garaventa-1

[Excerpt]

There are three primary categories of ARIA usage that apply during development. One involves static ARIA roles that don't require any scripting, the second involves ARIA roles that are basically static but still require some scripting to properly implement, and the third involves ARIA roles that cannot be used without comprehensive scripting in order to properly implement. Not having a proper understanding which roles belong to which category is a mistake that developers often make, which can cause interactive web technologies to become totally inaccessible to assistive technology users when the wrong roles are used in the wrong places or when the proper scripting is missing from roles that require it.

This is especially important when building markup templates as part of framework designing, and how this compares with reusable interactive component design, the two of which are not equal. The reason being that only static ARIA roles can be safely added to static markup templates without concern for scripting, yet all others such as pseudo and fully interactive ARIA roles cannot be safely added to templates without proper scripting to process these roles after content is rendered. These differences directly impact the job roles of those who are implementing ARIA roles within web technologies. For example, it is safe for web designers with little to no knowledge of scripting to utilize the static ARIA roles within content templates without negatively impacting accessibility. However if the same people attempt to do the same thing using interactive ARIA widget roles without strict cohesion with developers or a framework for synchronizing the requisite scripting, then they will break accessibility for assistive technology users instead.


Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
<EMAIL REMOVED>
415.624.2709 (o)
www.SSBBartGroup.com