The domain of web accessibility defines how to make a web content usable by a person with disabilities. Some people may use assistive technologies to interact with the content. In order to do this, the software needs to understand the semantics of the content.
ARIA stands for Accessible Rich Internet Application. The incorporation of this is a way to provide the proper semantics for custom widgets to make them accessible with assistive technologies. So, applying ARIA to a web page means that it only applies to screen reader, but not visually. This authoring practice is a guide on how to use WAI-ARIA to create ARIA to improve accessibility.
ARIA enables authors to describe nearly any user interface component in ways that assistive technologies can reliably interpret, thus making components accessible to assistive technology users. This can be both an advantage and a disadvantage of using ARIA, authors can override the roles of the semantics.
Essentially, this authoring practice provides a guide on how to implement accessibility to a web page by focusing more on the keyboard navigation and the structure of the accessibility tree.
When we inspect the Traveloka web page, under the Accessibility devtools, it can be seen that it is not very accessible. Though there are quite a lot of things that can be discussed about it, we are focusing on the accessibility of the flight product search form.
When using a search form, a user should:
The search form uses a lot of custom widgets to create the elements. Hence, we can apply the WAI-ARIA Authoring Practice on those widgets to provide more accessibilities.
Example: Products Search Form
The search form tabs are created using a div element, using CSS and JavaScript to make it act and look like a tab widget, with the name and role not being specified. The tablist is not connected to the respective panels. The tablist is also not focusable because it was created only with a div element and div elements are not accessible by default and must be provided with ARIA properties to make it accessible.
Status: Not Accessible
Link: https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-1/tabs.html
Example: Multi-city / One-way radio button
On top of the flight search form, there is a custom radio button for choosing a single flight or a multi-city flight. However, they are not accessible since the buttons are generated using CSS pseudo elements and the original input button is hidden both visually and to screen readers. This is an issue because CSS generated contents are inserted into the page after the DOM loads, so the content is not announced by screen readers.
Status: Not Accessible
Link: https://webdesign.tutsplus.com/tutorials/how-to-make-custom-accessible-checkboxes-and-radio-buttons--cms-32074
Example: Airport location input
The origin and destination inputs on the flight search form provides keyboard accessibility. When a user enters an input, a list of locations will pop up. The list is also accessible, but this has no focus indicator and the user will not know which option on the list is currently selected.
Status: Accessible, but has no focus indicator
Link: https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/grid-combo.html
Example: Reverse button
Between the origin and destination inputs, there is a reverse icon that looks like a button. However, it’s the child of the origin input’s parent element and it is an svg element. It’s styled to look like a button, but it doesn’t have the button role. So, the element must be made into accessible buttons by adding some ARIA properties.
Status: Not Accessible
Link: https://www.w3.org/TR/wai-aria-practices/examples/button/button.html
Example: No. of passengers input
The input on the passenger section of the form is considered a spinbutton element. The popup that contains the input is inaccessible since it doesn’t even stay open when the element is trying to be inspected.
Status: Not Accessible
Link: https://rawgit.com/w3c/aria-practices/issue125-add-spinbutton-example/examples/spinbutton/spinbutton.html
Example: Maximum passengers reached
Once the maximum number of passengers has been reached, a tooltip is shown to give that information to the user. This tooltip is inaccessible since the screen reader doesn’t tell the user that it has shown. However, currently, the implementation of the WAI-ARIA Authoring Practice on this widget is still an open issue on Github.
Status: Not Accessible
Link: https://codepen.io/Moiety/pen/LaPvWy, https://www.accessibility-developer-guide.com/examples/widgets/tooltips/
Example: Return date
When the tab key is pressed from the departure date input, it goes to the return date checkbox, with a focus ring on the border of the checkbox. The checkbox is also correctly associated with its label. This shows that the checkbox is accessible.
Status: Accessible
Link: https://webdesign.tutsplus.com/tutorials/how-to-make-custom-accessible-checkboxes-and-radio-buttons--cms-32074
Example: Date picker
The date picker pop up on the date selection shows an example of a grid. However, it was rendered using div elements to create the grid widget, making it unfocusable. This widget could me made accessible by adding a grid role to the date picker.
Status: Not Accessible
Link: https://www.w3.org/TR/wai-aria-practices/examples/grid/dataGrids.html
Example: Seat class
The listbox is shown when the seat class input is active. However, similar to the spinbutton pop up, this listbox pop up also disappears when the inspect element is opened.
Status: Not Accessible
Link: https://www.w3.org/TR/wai-aria-practices/examples/listbox/listbox-collapsible.html
Example: Log in / Register
The login and register links, located at the bottom of the product search form, are built using the correct semantics, so it doesn’t need to be given any ARIA properties since they are already accessible by default.
Status: Accessible
Link: https://www.w3.org/TR/wai-aria-practices/examples/link/link.html
Example: More options on flexibility
The more options disclosure widget will be shown once the user has chosen both the origin and destination. It is accessible, but it has no focus ring around the element. An improvement to this can be made by adding CSS to the focus pseudo element.
Status: Accessible, but has no focus indicator
Link: https://www.w3.org/TR/wai-aria-practices/examples/disclosure/disclosure-faq.html