Introduction To Accessible Rich Internet Applications (ARIA)

ARIA is the bridge design component between the standard HTML specification and the dynamic features of complex website applications. The ARIA specification defines how information can be provided to assistive technologies like screen readers, to create a better user interaction experience. The assistive technology user agent, like screen readers, gathers information from the ARIA markup and the browser’s application interface, and presents it in a meaningful way to the user. Using ARIA, developers can make advanced web applications accessible and usable to people with disabilities. That is, ARIA provides a framework for adding attributes to identify features for user interaction, how they relate to each other, and their current state. That is, if you create a web page action that a user can click, or tap, or drag, or drop, or slide, or scroll… a user must also be able to navigate to that widget and perform an equivalent action using the keyboard.

One of the greatest challenges in learning to implement and test ARIA properly, is that ARIA is an invisible technology. Sighted observers cannot see where ARIA is applied, nor when issues are caused as a result of its use. The accessible use of ARIA learning can only be achieved through experimentation and experiential learning. There are two different structure trees within every web page, the Document Object Model tree and the Accessibility Model tree. The web page information can be enhanced with visual styling by adding CSS classes and assistive technology styling by adding ARIA attributes.

The World Wide Web (WWW) is changing. Static web pages are being replaced by dynamic web sites with desktop-style web applications that make heavy use of JavaScript and other scripting control interfaces. Designers are creating web applications That has the potential to dramatically improve the responsiveness and usability of the web, but many users are at risk of being excluded due to accessibility gaps. Accessibility of web content requires semantic information about widgets, structures, and behaviors, in order to allow assistive technologies to convey appropriate information to persons with disabilities. These semantics are designed to allow a web developer to properly convey user interface behaviors and structural information to assistive technologies in document-level markup.

Watch the video, and then using a screen reader and a keyboard navigate the website to experience the assistive technology perspective.

• screen reader windsor homepage review (MP4)
• City of Windsor Home Page

Do Not use ARIA if native HTML can provide accessibility. Native HTML elements (like <button>, <a>, <input>, etc.) have built-in accessibility features. Use them instead of creating custom components with ARIA. For example, instead of using a <div> with role="button", use a <button> element.

Use ARIA to Enhance, Not Replace, Native Semantics. ARIA should enhance the accessibility of elements, not replace the inherent semantics of HTML. For example, if you need to create a complex widget like a custom dropdown, ARIA can help provide the necessary role and state information to assistive technologies.

Use Roles, States, and Properties Correctly.
ARIA roles define what an element is (role="button").
ARIA states indicate the current condition of an element (aria-expanded="true").
ARIA properties provide additional information about an element (aria-label="Close").

Ensure ARIA States and Properties Are Updated Dynamically. If an element's state changes (a dropdown menu is expanded or collapsed), ensure the corresponding ARIA state (aria-expanded) is updated accordingly.

Avoid Overuse of ARIA. Overusing ARIA can lead to confusion and errors in assistive technologies. Only use ARIA when necessary to convey additional information or when HTML alone is insufficient.

Ensure ARIA Does Not Conflict with Native Semantics. Be cautious when applying ARIA roles that might conflict with the native semantics of an element. For instance, applying role="button" to a <button> element is redundant and might cause issues.

Use ARIA Landmarks to define the web page layout. ARIA landmarks (role="navigation", role="main", role="banner") help users navigate the page more easily, especially those using screen readers.

Use aria-live Regions for Dynamic Content. Use aria-live to announce dynamic content changes (like error messages or updates) to screen readers. This helps users who are not visually following the changes.

Provide Keyboard Accessibility. Ensure that interactive elements with ARIA roles are also accessible via the keyboard. ARIA does not handle keyboard interaction by itself, so this must be implemented in JavaScript.

Document the Use of ARIA. Keep track of where and why ARIA is used within your codebase. This can help with maintenance and ensure that ARIA is being used consistently and correctly across the project.

Test with Assistive Technologies. Always test your site with screen readers and other assistive technologies to ensure that the ARIA roles, states, and properties are correctly conveyed and that they enhance the user experience.

Inability or difficulty navigating using keyboard or assistive tech.
For some of your users with disabilities, focus is the primary way of reaching everything interactive on the screen. So, you need to ensure that you have a logical focus order in the page. These users navigate focus in the document using either the Tab or the Shift-Tab keys on their keyboard. For these users, ensure the only things that are focusable are the interactive controls.
The way that you write your HTML dictates the order that things will be focusable in your page. CSS can rearrange the visual ordering of controls, making the interaction confusing. Instead of rearranging the visual ordering with CSS, move the element in the DOM.

Presentation of content or functionality that is not accessible to assistive technologies.
Sometimes web developers will use HTML attributes or CSS properties to visually hide elements on a webpage, but it is important to ensure that a high level of assistive technology accessibility is maintained.
aria-hidden: The aria-hidden="true" attribute is a property that indicates whether an element is visible or hidden to assistive technologies such as screen readers. When set to "true", it hides the element from assistive technologies while remaining visible to sighted users.
display: The "display: none" CSS property removes an element from the normal document flow and hides it from both sighted users and assistive technologies.
Class: The class="visually-hidden" technique hides content visually but ensures it remains accessible to screen readers by positioning it off-screen or setting its dimensions to zero.

Lack of user control over automated content changes.
Accessible Javascript event handlers.
Mouse Control: Mouse controls onFocus, onBlur and onClick responds to ENTER key on links and form controls. For other elements, ENTER and SPACE key presses must be detected.
Device independent: Using onChange and onSelect controls, add a submit button when used to trigger navigation.
Mouse Focus: When using onMouseOver and onMouseOut combine with onFocus and onBlur.
Device dependent: The onDblClick has no keyboard equivalent; So, should be avoided. list end.

Altering or disabling the normal functionality of the user agent (browser) or triggering events user may not be aware of.
ARIA common pitfalls.
Developers add ARIA attributes, but fail to add keyboard support and requisite scripting behaviors that match the Widget type.
Developers add focus movement and scripting behaviors that don't coincide with the elements that include valid ARIA Roles for that Widget type.
Developers add some ARIA Roles for a specific Widget type, but fail to add others that are required to complete the Widget type.
Developers add ARIA Roles, but fail to add required state or property attributes for that Widget type.
Developers don't understand how ARIA usage is supposed to effect functionality within Assistive Tech.