IA, UX, UI- Information Architecture & User Experience, User Interface design- III- Standards / Guidelines-ARIA- At a Glance

[In the previous article https://www.dhirubhai.net/pulse/ia-ux-ui-information-architecture-user-experience-design-sutar-ffbpc/?trackingId=d8DRN783Tb2F0CDHlTRdXw%3D%3D , the UI, UX design scenario was discussed with introduction to ARIA]

RECAP: The UI and UX design activities and contents were discussed along with accessibility and ARIA.

Let's quick touch base to ARIA guidelines. As published by w3c https://www.w3.org/, the latest recommendation for ARIA is Accessible Rich Internet Application (WAI-ARIA) 1.2.

Here are simplest best practice guidelines

1. Use native HTML element or attribute with the required semantics & behavior rather than element with ARIA roles, state or property. With HTML 5 , it has added many semantic tags making it easier to stay away from ARIA role, state etc. Stick to native semantics unless absolutely necessary. e.g. the HTML5 <nav> element shall be used instead of the adding the ARIA role=”navigation” to a div element.
2. All the interactive controls or elements must be usable with keyboards and shall have an accessible name.
3. Avoid role="presentation"?or?aria-hidden="true"?on a?focusable?element.
4. Avoid hidden form instructions using an ARIA label.
5. If ARIA role is used then ensure it is used correctly, properly and meets the use expectations. e.g. if <div> is used with ARIA role as "button" then ensure to implement JavaScript to provide keyboard interactions as expected from a "button".
6. Use ARIA to add semantics instead of taking away the existing semantics. Web authors generally end up overriding accessibility semantics with ARIA usage. e.g. if a grid element is created and then added the ARIA role “log” to it, the assistive technology users would not be able to perceive it as a grid.

ARIA examples

The WAI provides a suite of web standards for using ARIA in HTML and there are more than a dozen of roles, states, and properties available for defining accessible user interface elements, including:

• alert
• alertdialog (name required)
• application (name required)
• article
• banner
• blockquote
• button (name required)
• cell
• checkbox (name required)
• columnheader (name required)
• combobox (name required)
• command
• complementary
• composite
• contentinfo
• definition
• dialog (name required)
• directory
• document
• feed
• figure
• form
• grid (name required)
• gridcell
• group
• heading (name required)
• img (name required)
• input
• landmark
• link (name required)
• list
• listbox (name required)
• listitem
• log
• main
• marquee (name required)
• math
• meter (name required)
• menu
• menubar
• menuitem (name required)
• menuitemcheckbox (name required)
• menuitemradio (name required)
• navigation
• note
• option (name required)
• progressbar (name required)
• radio (name required)
• radiogroup (name required)
• range
• region (name required)
• row
• rowgroup
• rowheader (name required)
• scrollbar
• search
• searchbox (name required)
• sectionhead
• select
• separator
• slider (name required)
• spinbutton (name required)
• status
• switch (name required)
• tab
• table (name required)
• tablist
• tabpanel (name required)
• term
• textbox (name required)
• time
• timer
• toolbar
• tooltip (name required)
• tree (name required)
• treegrid (name required)
• treeitem (name required)
• window

How to test if a website has accessibility support? There is way to test it manually - https://a11ysupport.io/tests/.

The UX design principles will be covered in following articles.

Bibliography

So far so good!

DISCLAIMER: No copyright infringements are intended.