Accessibility concepts and standards

[ seh-man-tiks ]
noun
the meaning of a word, phrase, sentence, or text

What is Semantic HTML?

Semantic HTML is HTML with built-in features that natively describe the content and its role. Some examples: <header>, <footer>, <article>, <section>, and <nav>. These elements/tags help browsers, search engines, and assistive technology software understand the structure and purpose of page content.

Non-semantic elements like <div> and <span>, which are intended for layouts and visual styling, don't have these native semantic features and require extra information to make them accessible. To match the capabilities of semantic HTML, a non-semantic element like a DIV will always require additional attributes, styling, and javascript, resulting in additional development time and a larger code footprint.

Below you'll find examples of: (1) a non-semantic DIV button, (2) the same DIV button made accessible, and (3) a button using the native HTML BUTTON element. Styles not included in the examples.

Code example: Non-semantic button

This inaccessible button is made with a DIV, using the role attribute to function like a button when clicked. Buttons like this are still fairly common on the web. Though it will work perfectly fine for most sighted users using a mouse, screen reader and keyboard users may not be able to activate this button. Footprint: 90 characters (92 bytes)

<div id="nonSemanticButton1" class="non-semantic-button-1" role="button">
  Subscribe
</div>

Code example: Non-semantic button, made accessible

This is the same DIV button, made accessible with additional Javascript and a tabindex value of 0 for keyboard focus support. Footprint: 565 characters (582 bytes)

</script>

Code example: Semantic button

This button created with the BUTTON element is just like the “Non-semantic button, made accessible” button above, but its native semantics make it inherently accessible to screen readers and keyboards. No additional coding is needed for basic functional accessibility. Footprint: 90 characters (97 bytes)

Subscribe

Footprint comparison

As you no doubt observed, the natively-accessible BUTTON element example takes up less disk space than its fixed non-semantic counterpart. Making the non-semantic DIV button accessible requires 565 characters (including spaces) at 582 bytes, which is 6 times the size of the semantic BUTTON element example.

Screen reader semantic interpretation

How does screen reader software interpret HTML elements? When a screen reader like Apple Voiceover focuses on an element on a page, it will announce (read aloud) the label (if any) followed by the element name. Most screen readers will announce "Subscribe, button" for all three button examples on this page, regardless of how accessible they are. If the screen reader recognizes the element, it will announce it to the site visitor.

Best practices regarding native HTML

As a general rule of thumb: preference should always be given to native semantic HTML elements over their non-semantic counterparts like DIV and SPAN. It's faster and takes up less space, so why not? There's nothing inherently wrong with a styled DIV button that contains the ARIA role attribute, styling, and Javascript for accessibility; in some cases (e.g. fixing an old site) it may be easier and faster than fixing the template with semantic HTML. However, it's important to keep in mind that retrofitting elements (e.g. making a DIV behave like a BUTTON) don't always generate comparable results. Bugs and various software incompatibility do exist, so you'll likely find native semantic HTML easier to work with.

Captain Lorca might take issue with my reinterpretation of his quote, but it fits here. It's an accurate summation of the importance of properly-structured web content, which is necessary for machines and humans alike to consume, understand, and process. Without context, content loses its meaning. In short, we make the content (e.g. a button) accessible so that its context (subscribing) can be understood and used (activating the button to subscribe) by the user.

Let's take a look at this basic example of a fictional ship inventory page for the U.S.S. Discovery.

Every element in this HTML example has a specific purpose and therefore provides context for the content it contains. It's important to use the correct elements for their intended purpose, otherwise the context will be obfuscated. If we wrapped the "The USS Discovery was a Crossfield-class..." block of text with an H2 rather than a paragraph tag, what does this communicate about the enclosed content to the user? Would this be appropriate? Will it convey the same meaning?

What about that OL element and all those LIs? Does the context change if we separate these items with line breaks instead?

Also known as WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications), ARIA is an advanced "suite" of dynamic accessibility-focused attributes that are meant to complement native HTML. Its power is matched only by its potential for misuse, because adding ARIA to an element can (and often does) make its accessibility worse. Developers reading this are advised to use ARIA only if they know what they're doing, and as a last resort.

To quote the first rule of ARIA:

"If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."

ARIA is organized into roles and states & properties, populated by additional sub-categories. ARIA is somewhat of a rabbit hole and far too expansive to cover adequately in this space, so for now keep in mind that it should be used sparingly.

The acronym "POUR" describes four main aspects of accessible content. If you find yourself stuck or if you're not sure what to look for, it might help to pause and ask the following questions:

PERCEIVABLE

Can your website visitors see and hear the information on the site?

OPERABLE

Can your visitors navigate the site independently using the assistive tools of their choice?

UNDERSTANDABLE

Can your visitors comprehend the meaning of your content?

ROBUST

Does your content work well on different platforms and devices? This concept includes assistive technology, so there's some overlap here with "Operable."

WCAG (Web Content Accessibility Guidelines) should be treated as the ultimate source of truth. Published in 2023, WCAG is currently on version 2.2 and has three conformance levels representing different amounts of accessibility adherence: A, AA, and AAA.

When developing and testing for accessibility, UIC developers should target WCAG 2.2 AA standards. Devs are encouraged to adopt WCAG 2.2 level AAA (the highest level) whenever possible.

The official WCAG documentation, which contains over 60 Success Criteria items, is a informative but extremely technical resource, and can be off-putting due to its dry approach and organization. You may find it easier to digest if you consult WCAG's "Understanding" documents, which explain the Success Criteria and how to meet them in plain English.

The IITAA techniques page, maintained by the State of Illinois, also explains WCAG SC in plain English. It's direct, shorter, and less detailed, but is a solid quick reference guide.

Standards are good to know, but how do you implement them? What does that look like? A quick online search will return a plethora of accessible code examples with varying degrees of legitimacy, so how do you know what code examples are worth investigating if you're starting out? Below is a short list of recommended resources that contain trustworthy code examples that can aid in accessibility implementation.

WAI Tutorials

The W3C Web Accessibility Initiative (WAI)'s Tutorial page is an excellent resource if you need to learn the fundamentals of page structure. It goes quite in depth and has a lot of examples for not only page structure but also menus, images, tables, forms, and carousels.

Washington University's "Accessible University" before & after examples

In 2021, Washington University released a before and after example page demonstrating inaccessibility and their implemented fixes. Though the last release was three years ago, the "After" example page adheres to WCAG 2.2 standards and is a great example of proper functional accessibility. Highly recommended.

ARIA Authoring Practices Guide (APG)

Last (but certainly not least) is the crucial concept of "Expected behavior". Simply put, Expected behavior is the desired outcome when a user interacts with a web element. For example: if a user tabs to a button labeled "Reload this page", the page must reload when the user presses the Enter key. If it doesn't, expected behavior is not met and the element is very likely not accessible.

For your reference, you'll find an "Expected behavior" table on both the How to test accessibility manually with a keyboard and the How to test accessibility manually with a screen reader pages. These tables describe common web elements, what keys are expected to activate the element, and the outcome to expect if the activation is successful.