This is the first of a series of articles relating to Web Accessibility, breaking down how I understand each aspect of it, including things like best practice coding, testing, what your mark-up really tells impaired users and the general theory behind creating Accessible content. I'll also try and point out any tips I've uncovered to try and smooth out the, sometimes rock, path to validating a site as Accessibly compliant.
A loose definitionBefore we really get into it the detail we probably attempt to define the term 'Accessibility'.
Breaking it down to a succinct definition would be something like,
"Accessibility defines the way you communicate how a user can interact, but not the behaviour of that interaction".
At a basic level this means that you have to communicate to a user how they can interact with your content, but you cannot dictate to them the method if that interaction. As an example you cannot force a user into a new window (target="_blank") as this is dictating the method of interaction, not the message contained within it.
This makes sense from a 'web etiquette' point of view when you consider that it is quite impolite to try and tell users what to do.
This isn't restricted to just code based interaction. It also includes the medium used in that communication, i.e. is the user using a regular web browser, a screen reader or any other form of viewer. Remember that your message can be communicated as text or audio.
Aims of AccessibilityThat brings us nicely to the aims of Accessibility. Because we have now qualified the term Accessibility with the definition above we can identify what the aims of implementing Accessibility guidelines should achieve.
- Allow enabled and disabled users the same level of communication. Do not exclude partially sighted or hard of hearing users due to their impediment.
- Allow your users the ability to view your content in their chosen medium, it does not have to be exactly the same content, merely the same message
- If you provide a user with a choice you have to provide enough information to allow them to make an informed decision about that choice
- You must be able to accurately describe any choices (for example hyper links) outside of the context of the page, as an example if we have a hyper link with the text 'click here', outside the context of the surrounding content it means nothing, but if the same link were to say 'follow this link to view information about...' it would have the same meaning both within the page, and without.
This covers the basic concept of what Accessibility is, and the aims you should keep in mind when it is a factor of a web project. In the next article I'll discuss Accessibility standards, and go into depth about how you can actually start to make sure that your finished project will pass validation against those standards.