This is quite a fantastic tool for readers who depend on screen reader technology incapable of using mouse. Such readers are often restricted from using various websites and applications due to complex functionality. Tabbed interfaces, progress bars and sliders are some of the examples of such interfaces which cannot be used by disable people. However, with the inclusion of WAI-ARIA they can use the user interface because it fixes the shortcomings in such architecturally complex pages. Thus, users reliant on assistive technology can use websites or application when WAI-ARIA is used to enhance functionality.
WAI-ARIA allots roles to elements and provides those roles with properties and states. For example, the application may be utilizing the list item as a linked element to categorize content; however, without an ARIA-checked attribute to the role the screen reader will not be able to determine the functionality of the element. The presence of semantics alone does not add any identification. Adding the assistive element will make the device identify the function correctly. Header, h1 and nav WAI-ARIA attributes are mostly redundant for semantics; they speak for them. Instead using WAI-ARIA for elements which do not mean anything significant on their own makes it more useful and accessible.
The present status of WAI-ARIA is that it is still being worked upon just like HTML5 in web designing. Hence, these technologies will gradually fulfill the expectations from users. WAI-ARIA has become necessary to be included on elements which already express their meanings through their names. It can function as a stopgap providing accessibility for pages made with HTML5 while screen readers are becoming usable.
Let us look at this example:
<nav role=”navigation”> <ul>… </ul>
Javier Quincoces on 02-Mar-2018