Part 3: How to Fix It? ⬅YOU ARE HERE
The general idea behind semantic markup from a dev perspective is that you can look at the markup and tell (to a degree) what the inner code is based on what its container is. For instance, I can tell the body of this post is an article because it’s wrapped in
<article>. This can also be deciphered with the navigation, footer, etc…
Some common landmarks are:
|HTML 5 Tag||Role|
The navigation has to be keyboard accessible and have the ability for tabbing through it. Make sure you wrap it in a <nav> and test the navigation with a keyboard and without a mouse (keyboard tips). In addition, the navigation must be consistent.
Next up is ARIA (a good guide can be found here). Mozilla defines ARIA as:
ARIA is a set of special accessibility attributes which can be added to any markup, but is especially suited to HTML. The role attribute defines what the general type of object is (such as an article, alert, or slider). Additional ARIA attributes provide other useful properties, such as a description for a form or the current value of a progress bar.
Simply put, ARIA gives roles to elements, such as an error message, so that screen readers can better describe the element. For instance, I can look at a yellow or red box and tell that it is a message alerting me. However, a user using a screen reader is unable to experience the alert. In this case, we could give the message box the ARIA role of alert. A full list of ARIA roles can be found here.
Adding it to elements is trivial, as it is just an attribute.
<div role="alert">This is an important message</div>
Forms / Inputs
WebAIM has a great article on making forms accessible. ThatDevGirl also has a slideshow on the subject. We found that a good portion of our forms did not have labels with every input, the navigation messages were not as descriptive as they should be, nor was the tabIndex always in the correct order.
Try to use
<legend> when you can and make sure the layout of the form is “logical”. More information can be found here.
The error messages have to be specific, so validation per field should not be a general statement such as, “there was an error with your submission.” Links in the error message that guide you to the portion of the issue form are preferred.
Mozilla also has an article describing error messages.