HTML5 has improved greatly over the years. One of its biggest successes was trying to make the World Wide Web more accessible by moving in a more semantic direction. It introduced several new semantic elements such as:
<section>, <article>, <aside>, <hgroup>, <header>, <h1> through <h6> level headings, <footer>, and
<address>. While these new elements are great, they don’t actually do anything.
They crack the door open slightly to provide value to assistive technologies that can expand upon the elements through programming. These new elements have been made standards by W3’s Consortium. While these are made standards, not everyone is required by law to follow them. The biggest problem with HTML5 and its accessibility features is the compatibility of the browsers that interpret the markup. Most development companies follow these standards but they are free to take their own direction when building a browser.
Accessibility and Compatibility
HTML5 has great accessibility features but there are still some issues. Because HTML5 is constantly evolving, it makes it difficult in the development stages. Here are some of the current issues:
- Competing video formats are making HTML5 based video playback almost impossible to implement
- Inconsistencies between web browsers
- The heading structure is not useful in assistive devices
- Interpretation and support among technology products
One of the top browsers that has kept current with the evolution of HTML5 is Mozilla’s Firefox. This screen shot shows which major browsers support HTML5 accessibility attribute features:
Every developer and designer should ensure their website covers as many disabilities as possible to provide users with a rich accessible experience. That’s where ARIA (Accessible Rich Internet Applications) or WAI-ARIA comes into play. ARIA defines the roles, names, descriptions, values, and states of objects to help assistive technologies, such as screen readers to better understand the information laid out on the page.
ARIA When and How
ARIA has a wide range of accessibility elements. For that reason we will only be covering a few examples in this section. The elements that will be explained are better known as the “Landmark Roles.”
The document Role
The document role helps assistive technologies switch from normal browsing mode into a mode more suitable for interacting with web documents. Most webpages are considered a document because you often read them, while a document role still supports users to have interactions. This is often inserted into the body element.
The banner Role
The banner role should only be used once within the html markup. It is usually used within the top of the page in the <header> or any element that contains the prime heading or in-page title of the site.
The complementary Role
The complementary role is generally used in the <aside> or sidebar section of the HTML document. The complementary role element lets assistive technologies know that whatever is inside this area, it is complementary to the main content.
The contentinfo Role
The contentinfo role is used within the area that contains copyrights and links to privacy statement information. It is generally used in the <footer> element of your markup.
The form Role
The form role is used by a screen reader to let users know that they can fill out a form. On some screen readers, users have quick keys to direct them to this sections of the page quickly. There is a lot more that goes into forms and it is recommended that you read the help documentation provided by W3.
The main Role
The main role in ARIA is better explained as the most important element for screen readers and users alike. It is essentially used a link to “Skip to the main content”. It helps users know that this is what they are essentially looking for on a page.
The navigation Role
The navigation role element is used in the navigation or <nav> element. The most important thing for any website is to be able to clearly navigate it. The navigation role tells screen readers that this is your navigational links.
The search Role
The search role tells assistive technologies that users can search the website through this section. It is often used in a text input field labeled with role search.
<input type="text" name="search" role="search">