-
Notifications
You must be signed in to change notification settings - Fork 0
Accessibility
Source:
- https://www.gcis.gov.za/guidelines/website/website-accessibility (Accessed on 15 June 2024)
- 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).
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 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 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 likesvg
orimg
- Mark up lists properly using
ol
,ul
andli
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 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: 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: 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:
- Make the document readable without stylesheets.
- Ensure that changes to dynamic content are reflected appropriately
- Make dynamic content usable without Javascript. If not possible, clearly indicate that using things like a
noscript
tag.
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: 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: 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.
Documentation compiled by: Sebastian Guimaraens, Kivashin Naidoo, Michael Horwitz, Vincent Feistel, Caelan Hill