Hey there! You're using an out-of-date browser, so this site probably looks pretty funny. Upgrade your browser for the full experience.
A Piece of the Pie For All

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

In Part 3 of our ongoing series on Website Accessibility, Nick Stewart gives us a brief lowdown on how to code semantic HTML for current accessibility standards.

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:

Accessible Rich Internet Applications (ARIA) defines ways to make Web content and Web applications (especially those developed with Ajax and JavaScript) more accessible to people with disabilities. For example, ARIA enables accessible navigation landmarks, JavaScript widgets, form hints and error messages, live content updates, and more.

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 <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.

Born and raised in
Louisville, Kentucky.

502.498.8470

223 S. Clay St

Work With Us

  • This field is for validation purposes and should be left unchanged.