Website Accessibility: How to Fix It? (Part 3 of 4)

Part 1: What is Accessibility? Why should I care?

Part 2: Assessing Your Accessibility (What to Fix)

Part 3: How to Fix It? ⬅YOU ARE HERE

Part 4: Testing

Semantic Markup

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 <header> banner <nav> navigation <main> main <aside> complementary <section> region <article> article <footer> contentinfo <form> form

Navigation

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.

ARIA

Next up is ARIA (a good guide can be found here). Mozilla defines ARIA as:

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 <fieldset> and <legend> when you can and make sure the layout of the form is “logical”. More information can be found here.

Error Messages

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.