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 <header> banner <nav> navigation <main> main <aside> complementary <section> region <article> article <footer> contentinfo <form> form
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.
Website Accessibility: An ongoing series (Part 1 of 4)
By:Ben Wilson on 12/14/2017
Accessibility for the web (or any digital content) is a complex topic for content creators, marketers and anyone with something to say online. There are a handful of accepted standards and practices, but nothing official.Read More »
Website Accessibility: Assessing your Accessibility (Part 2 of 4)
By: Rebekah Beran on 12/28/2017
Part 1: What is Accessibility? Why should I care? Part 2: Assessing Your Accessibility (What to Fix) â¬ YOU ARE HERE Part 3: How to Fix It? Part 4: Testing So you’ve heard talks about “Web Accessibility” lately – and maybe you have already read our part 1 to Website Accessibility to learn more about it – so the lingering question is, how do you know if your site is accessible? You could do a Google search and read through the all of the information from W3C or Section 508, but let me save you some of that time! This post will rundown which areas to examine, what to look for, and how to tell if improvements are needed. We’ll group these into two parts, each with their own sections and questions to ask yourself.Read More »