Key principles for creating accessible web content
As already mentioned the Web Content Accessibility Guidelines WCAG 2.1 were developed by W3C and they explain how to make what is seen and heard on a web page accessible.
There are 12 guidelines that are grouped in four principles for creating accessible web content:
For each of these guidelines, success criteria and techniques were developed. Using the criteria and techniques web developers can check the level of conformance of their content to WCAG 2.1. There are 3 levels of conformance, starting from A(lowest), AA to AAA(highest).
Let’s take a more in depth look at the four principles of the WCAG2.1.
Principle 1: perceivable
Information and user interface components must be presented to users in ways they can perceive. This means that users must be able to discern the information being presented (it can’t be invisible to all of their senses).
An example for this principle is missing alternative text for images. Alternative text provides a textual alternative to non-text content in web pages. Alternative text serves several functions:
it is read by screen readers in place of images, allowing the content and function of the image to be accessible to those with visual or certain cognitive disabilities
it is displayed in place of the image in browsers, if the image file is not loaded or when the user has chosen not to view images
it provides a semantic meaning and description to images, which can be read by search engines or be used to determine the content of the image from page context alone.
For a sighted person it is clear that this button could take the user to a shop in order to purchase items. The code used for web pages is called Hyper Text Mark-up Language, commonly referred to as HTML.
Let’s take a look at the source HTML that created this image link:
<a href=""><img alt="" src="ButtonImage.png"></a>
As you can see the alt-Tag(alt=””) in the image element is empty, providing no information for the screenreader. Therefore, those who depend on the alt-tag being read aloud would just learn this is a link to an unknown target. This is not only unhelpful for the blind person but also the shop will lose potential customers.
Principle 2: operable
User interface components and navigation must be operable. This means that users must be able to control the functions available on the interface (the interface cannot require interaction that a user cannot perform).
An example for this principle would be an interface that is operable with a single input device such as a keyboard or switch access for those who cannot use a mouse or other gesture input. HTML provides many standard elements such as buttons, input fields, links etc that offer interactions for different purposes and these need to follow the WCAG 2.1 guidelines to ensure accessibility.
In order to see how this principle works in practice, try out the following exercise:
Go to a copy of this page which is hosted on the MOOCAP partners website.
Using just keyboard access or a single input device other than a mouse, and navigate to ‘Button 1. If you are using a keyboard, tab there and then select the enter key to activate the button. See what happens and then try the same process with the button labelled ‘Button 2’.
Note: if you find that you are unable to do this, it may be that ‘Full keyboard access’ has been disabled. Information is available for Mac users on how to enable that option.
You may notice that you are not able to focus on ‘Button 2’ with your keyboard. The second button is only a text-span that has been styled and programmed to appear as a button, although you will be able to activate it with a mouse.
This button would fail the WCAG 2.0 success criteria for keyboard accessibility. HTML could provide the tools to make such a span keyboard accessible and developers could also give it a proper role, which would be a ‘button role’.
However a better way would be to use the proper code for the button element in the first place and not to adjust another widget to fulfil a different purpose.
Principle 3: understandable
Information and the operation of user interface must be understandable. This means that users must comprehend the information as well as the operation of the user interface.
Web based interfaces should be built in a way that help users to avoid and to correct mistakes. We all make mistakes and errors but we also expect ICT to allow us to avoid and recover from our mistakes. Here is an example of a poor user interface representing a user’s account form that has three button after the three edit boxes, one says ‘edit account, the next says ‘ok’ and the last ‘cancel’:
For users it is unclear what the “OK”-button really does. Will the changes to the account made be applied or not? Another example can be seen in the following image of an error message:
This message just informs the user that something went wrong, but gives no indication regarding the reason for the error, nor does it help the user to find the error! The user has to guess what went wrong.
Principle 4: robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. In this case user agents are any software that retrieves and presents web content, like browsers (Chrome, Firefox, Safari…), media players (Quicktime, Realplayer, Windows Media Player…), plugins (e.g. those that help your browser perform specific functions), and other programs, including assistive technologies (pointers, magnifiers…).
Websites must therefore be created to support all this technologies.
How well do you think our example web page with its form complies with these guidelines?
© This work is a derivative of a work created by Johannes Kepler Universität Linz, and licensed under CC-BY BY 4.0 International Licence adapted and used by the University of Southampton. Erasmus + MOOCs for Accessibility Partnership.