Skip to content

Accessibility

Vincent edited this page Jun 15, 2024 · 3 revisions

Source:

  1. https://www.gcis.gov.za/guidelines/website/website-accessibility (Accessed on 15 June 2024)
  2. https://www.w3.org/WAI/wcag-curric/gid1-0.htm (Accessed on 15 June 2024)

This document contains a summarized version of the accessibility guidelines from 1).

Guidelines

Guideline 1: Text Equivalents

Guideline 1: Provide equivalent alternatives to auditory and visual content. Provide content that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content.

The general rule here is to add a short textual description of any non-text elements. One example is to include an alt tag in every img.

Guideline 2: Don't rely on colour

Guideline 2: Don't rely on colour alone. Ensure that text and graphics are understandable when viewed without colour

This guideline seems to not involve the markup itself, but rather the content inside the markup. The example used to demonstrate the guideline is as follows:

<!-- BAD. What if a user cannot see the colors (e.g. CSS fails to load)? -->
<p>
    There are two ways to get things done around here.
    The preferred method is shown in red.
</p>
<ol>
    <li>Your way.</li>
    <li>My way way.</li>
</ol>

versus:

<!-- GOOD. Even without styling the meaning is clear -->
<p>
    There are two ways to get things done around here.
    The second method, also shown in red, is preferred.
</p>
<ol>
    <li>Your way.</li>
    <li>My way way.</li>
</ol>

Guideline 3: Use mark-up properly

Guideline 3: Use mark-up and style sheets and do so properly. Create mark-up documents with the proper structural elements. Control presentation with style sheets rather than with presentation elements and attributes.

Here the guideline is to use the available HTML tags to your advantage to indicate the meaning of the document. For example:

  • Math equations should use the math element instead of something like svg or img
  • Mark up lists properly using ol, ul and li

One guideline the W3C specs state is to not use heading elements (i.e. h1, h2, etc.) to handle font size changes. I know I've been guilty of doing this, so really ask the question whether the element is in fact a heading.

Guideline 4i: Show changes in language

Guideline 4: Clarify natural language usage. Use mark-up that facilitates pronunciation or interpretation of abbreviated or foreign text.

Getting a little more niche, this guideline just requires indicating when the language the document changes. As an illustrative example, to mark up the following text containing a mixute of English and French:

Mother, he's asking you to go. He's saying, "Allons, Madame plaisante!"

You would write:

<p>
    Mother, he's asking you to go.
    He's saying, <span lang="fr">"Allons, Madame plaisante!"</span>
</p>

This helps screen readers effectively switch between languages.

Guideline 5: Use tables for data, not layout

Guideline 5: Create tables that transform gracefully. Ensure that tables have necessary mark-up to be transformed by accessible browsers and other devices.

This boils down to:

  • Properly annotate your tables with thead, tr and so forth
  • Don't use the table element for layout purposes

Guideline 6: Progressive Enhancement

Guideline 6: Ensure that pages featuring new technologies transform gracefully. Ensure that pages are accessible even when newer technologies are not supported or are turned off.

This ties into the idea of Progressive Enhancement. A website should still be usable if the user's device does not support the latest features. Some important checkpoints include:

  1. Make the document readable without stylesheets.
  2. Ensure that changes to dynamic content are reflected appropriately
  3. Make dynamic content usable without Javascript. If not possible, clearly indicate that using things like a noscript tag.

Guideline 7: Prevent uncontrolled actions

Guideline 7: Ensure user control of time-sensitive content changes Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped

Essentially don't do things that alleviate control from the user. This includes things like:

  • Auto-refreshing the page
  • Performing automatic redirects
  • Causing screen flickers without the user's "consent"
  • Causing involuntary movement of the UI

Guideline 8: Accessible embedded UI

Guideline 8: Ensure direct accessibility of embedded user interfaces. Ensure that the user interface follows principles of such things as accessible design: device-independent access to functionality, keyboard operability, and self-voicing.

This one seems a bit outdated, but I include it anyway.

Guideline 9: Device-independance

Guideline 9: Design for device-independence. Use features that enable activation of page elements via a variety of input devices

Don't assume a user has certain devices, such as a mouse. Granted, this may be difficult to do in some cases, but as a general guideline:

  • Supporting keyboard navigation is device-independant; keyboards can be simulated
  • Providing text equivalents (Guideline 1) can help with accessibility.