In honour of Global Accessibility Awareness Day, I thought I'd put down a few of my thoughts on the subject. I've been testing aspects of accessibility for a number of years now, mainly around websites, and there's such a wealth of information to take on it can be quite daunting. Here are some bits and pieces I've picked up along the way.
1) Look behind the rules
The WCAG 2 specification (which I usually am called on to test against, although I have looked at other specs as well) is immense, wide-ranging, and it can appear impossible to test for all the conditions mentioned. One approach I've found that helps is to learn more about the reasons the rules exist rather than blindly implying them - compared to the previous WCAG 1, it's much less prescriptive and more aimed at principles than specifics, so it's more important to understand the reasoning behind the rules rather than the rules themselves. One way of approaching this is:
2) Personas
Accessibility defects are much easier to understand when you approach them from the perspective of the user who they will affect - it's one thing raising an empty image alt tag, but it's much more liable to get fixed if you point out that a user navigating by screenreader will have no idea what is going on. Keep various differences of ability in mind (visual, audio, motor...) as you test; it soon becomes second nature to spot issues for specific user types.
3) Accessibility is not an add-on
Testing for accessibility should not be a separate activity; it works best when it is integrated into the main testing flow. While it makes sense to have a checklist of items to look for, it should be in the back of your mind throughout and issues should be raised as and when they occur. If left until the end the expense of fixing those issues will be far greater. It's also useful to get the designers on-board, to ensure the solution is accessible from the start - I've seen projects where the brand colour scheme would fail contrast tests, making it an uphill battle from the start.
4) Market-specific
In a similar way to choosing your browser set, while any accessibility issue still needs to be raised, the priority of the defect may depend on the target market - content should be available for everyone, but the users of the site will have individual needs and priorities that need to be catered for.
5) Accessible features benefit everyone
Remember the bad old days of SEO? You would build the site, then afterwards cram in as many SEO hits as you could (keyword stuffing, multiple links, etc.). That would result in an artificial bumping up of the SEO rating, which might drive people to the site, but they would find a site full of terrible content. SEO has now moved on so that good content improves rankings; good accessibility on a site will improve the general user experience. Simple example: a few years ago, zooming in on content was a feature of web browsers that very few people used and something that was rarely tested for. Now with smartphone pinch and zoom, it's second nature for people to do this on any site, so it's important this feature works; the fact it is an "accessible" feature is irrelevant. And in the spirit of inclusivity, why wouldn't you produce a site that everyone can view?
There were a number of events at our office for Global Accessibility Awareness Day, I'll try and follow this up with another post of anything interesting coming out of that.
1) Look behind the rules
The WCAG 2 specification (which I usually am called on to test against, although I have looked at other specs as well) is immense, wide-ranging, and it can appear impossible to test for all the conditions mentioned. One approach I've found that helps is to learn more about the reasons the rules exist rather than blindly implying them - compared to the previous WCAG 1, it's much less prescriptive and more aimed at principles than specifics, so it's more important to understand the reasoning behind the rules rather than the rules themselves. One way of approaching this is:
2) Personas
Accessibility defects are much easier to understand when you approach them from the perspective of the user who they will affect - it's one thing raising an empty image alt tag, but it's much more liable to get fixed if you point out that a user navigating by screenreader will have no idea what is going on. Keep various differences of ability in mind (visual, audio, motor...) as you test; it soon becomes second nature to spot issues for specific user types.
3) Accessibility is not an add-on
Testing for accessibility should not be a separate activity; it works best when it is integrated into the main testing flow. While it makes sense to have a checklist of items to look for, it should be in the back of your mind throughout and issues should be raised as and when they occur. If left until the end the expense of fixing those issues will be far greater. It's also useful to get the designers on-board, to ensure the solution is accessible from the start - I've seen projects where the brand colour scheme would fail contrast tests, making it an uphill battle from the start.
4) Market-specific
In a similar way to choosing your browser set, while any accessibility issue still needs to be raised, the priority of the defect may depend on the target market - content should be available for everyone, but the users of the site will have individual needs and priorities that need to be catered for.
5) Accessible features benefit everyone
Remember the bad old days of SEO? You would build the site, then afterwards cram in as many SEO hits as you could (keyword stuffing, multiple links, etc.). That would result in an artificial bumping up of the SEO rating, which might drive people to the site, but they would find a site full of terrible content. SEO has now moved on so that good content improves rankings; good accessibility on a site will improve the general user experience. Simple example: a few years ago, zooming in on content was a feature of web browsers that very few people used and something that was rarely tested for. Now with smartphone pinch and zoom, it's second nature for people to do this on any site, so it's important this feature works; the fact it is an "accessible" feature is irrelevant. And in the spirit of inclusivity, why wouldn't you produce a site that everyone can view?
There were a number of events at our office for Global Accessibility Awareness Day, I'll try and follow this up with another post of anything interesting coming out of that.
Comments
Post a Comment