The perpetual churn of new technologies and techniques can sometimes blind-side us to some fundamental issues in web design that we need to keep in focus all the time. One of these is accessibility which - for me - has been sharpened up by the brief but high-value book on the subject by Laura Kalbag, Accessibility for Everyone, published last year (2017) by A Book Apart.
I first wrote about accessibility back in 2009 and published a couple of pages on this site about the subject, focussing on the different legal requirements for making website content accessible as viewed from the UK and from France. I took these pages down a few years later, thinking that the subject was too technical and would be off-putting to potential clients. The take-away point now is that I had started to build websites with accessibility in mind and continue to do so today. It’s a default design approach which the title of this gem of a book confirms: everyone benefits when a site is made accessible to those with specific needs, even users who don’t have such needs. Design that helps those who need extra help is design that helps everyone.
Periodic sharpening of these skills (and perspectives) remains necessary and the above book serves that purpose amply. I recommend it to all web designers and developers as a valuable in-house refresher course. That said, repeated flag waving on this subject remains necessary and there can be no better start to the year than a post on this subject.
What is website accessibility?
Website accessibility is the removal of obstacles in a website’s design which might otherwise get in the way of any user accessing a site’s content. This operates at the level of single web pages and whole websites. Where on a page is the content that a user seeks? Where in a website is the content that a user seeks? A website that follows accessible design principles makes the answering of those questions in practice easy.
Who needs accessible design?
Allowing for the answer to that question being simply “everyone”, we can also be specific and mention a long list of potential stakeholders. This list will include users with disabilities and impairments. Some users will come to a website with visual impairments; think of colour blindness, short-sightedness, far-sightedness and astigmatism. Think too of more serious impairments such as some degree of sight loss perhaps caused by macular-degeneration or glaucoma. Other users will come to a website with physical limitations; think of arthritis, muscular dystrophy. Think about those with repetitive strain injury. (Maybe, like me, you prefer to use a vertical mouse.)
There are other categories of impairment that might need consideration at the design stage. If you are working on a website with audio or video content, this is likely to present problems to those who were born with a hearing loss or those who acquired one with age or in accidents. A separate category of disability involves impaired cognition, perhaps effecting memory, attention or information retrieval.
Another line of reasoning states that browsing on mobile devices with their smaller screens requires all sorts of additional considerations, not least for unimpaired users. Increasing the space around menu links, for example, caters for fingers in a way that mouse cursors don’t per se require.
Why should a website cater for people with these particular needs?
Two main reasons are offered to justify thinking about these groups of people during the design process.The first is ethical and argues that no-one should be excluded from accessing your website’s content. The second is commercial. Laura Kalbag states that an estimated 12.1% of the population of the US have some form of disability, whilst in the UK some 16% of working-age adults have some form of disability. Not only are there real people behind these statistics, some of them may also wish to become paying customers, members or partners, so this argument runs. You be the judge of which is the more important.
What resources exist for achieving an accessible website design?
I’m not going to attempt even a slim summary of Laura Kalbag’s book. Far better that you buy yourself your own copy. What I’ll try to do here is to list just a few basic strategies that a solo web designer can think of employing each time a page is put together. Web design studio teams will probably have their own accessibility specialist whose input is mandated from the very first client meeting. Accessibility is a wide discipline and it’s almost too much for a single, solo designer to manage to tick every box that this discipline requires. But there are some strategies that yield high-value results. Here’s my selection:
1. Think semantically and create a page hierarchy
Every page has to have a title tag, an h1 tag. This is basic stuff but it can be forgotten in the rush to print. Pages can have more than one h1 tag, but I prefer to have just the one. Secondary headings in the form of h2 tags should then cascade down the content as required.
Giving the content of each page a structured hierarchy using these tags helps screen-reader software to understand the way a page’s content has been organised. You should be doing this anyway because this is the basis of page design that is also best for search engines.
2. Attend to proper code for lists, links, images and forms
2a. Lists
Lists are straightforward in that the HTML code is easy. Just use either ul tags (for un-numbered bullet points) or ol tags (for numbered bullet points) with li tags for each list item as required. Screen-reading software will generally handle these well, reading each aloud starting with the word “bullet”, allowing the user to jump to the next one with a touch on the Tab key. This is semantically better than starting each point as if it were a paragraph or new line.
2b. Links
The humble a link shouldn’t be that complicated but:
- it should ideally be easy to spot by being visually different from text that surrounds it;
- it should ideally have an underline on hover;
- it should use descriptive text that is not of the “click here” variety; “Smith’s detailed explanation can be found here” is a better way to word a link;
2c. Images
Every image requires an alt tag. Screen-reader software will read this aloud, so make it useful but not excessively descriptive. If the image is decorative and plays no significant part in the textual argument, leave thealt tag empty, as in alt="".
2d. Forms
Forms can be scary, can’t they? They straddle the boundary between content and code. The first step in designing forms is to inhale deeply.
Your best hope is that the CMS that you use to build a site uses a form-building module that handles the bulk of the complexity for you. Part of the labour required is a styling process; the other part is in providing a graceful and forgiving validation process, one that hand-holds the user through the form-filling process. Build your form then validate it using the resources I’ll be mentioning in 4a - 4d below.
3. Separate your styling from your content
Some screen-reading software allows users to apply their own visual styling to a page’s content. That’s difficult to do if you’ve built the page with CSS styling that’s in-line with the HTML code. The two should be separate. Apart from anything else, a site with separate content and style sheets is easier to maintain.
I’ve not yet found a WYSIWYG text editor that doesn’t muck about with the source code, repetitively injecting styling mark-up within the HTML, when all that can be done by simply using semantic mark-up (or paragraphs, headings, lists, etc), so I don’t use one and usually don’t provide one for my clients. Keeping the content editing free of styling is best all-round. The external CSS styles will handle the requirements and help leave the code clean.
4. Verify your code
4a. W3C web standards testing
All of the above - and more - becomes second-nature after a while. But it’s only natural that errors slip through. I usually run an on-line evaluation of a new page’s code using the W3C validator. The results of this will give you some idea of any errors you’ve made. Don’t aim for perfection:
- yellow warnings may be OK to leave (examine what they are and see what the validator says about them);
- red errors which it flags up should be fixed straight away;
- if it says “Document checking completed. No errors or warnings to show”, give yourself a pat on the back.
Some of the errors and warnings that are flagged up may originate from the templates used in your CMS’s theming files - and therefore be visible on every page of the site. Fixing these may be tricky but, once done, they won’t surface again.
4b. WCAG guideline testing
The Web Content Accessibility Guidelines are equally complex but well-worth devoting a bit of time digging into. WCAG is part of the W3C consortium and it addresses principles and guidelines for developing sites that can be used by those with specific impairments. Laura Kalbag’s book provides the most digestible coverage of this but you can get an idea of the complexity of their work by checking the Web Content Accessibility Guidelines website.
I recommend having a look at Emerge Interactive’s WCAG Accessibility Checklist, a nicely laid-out Android app that offers a concise to-do-list that clarifies the three WCAG Levels of A, AA and AAA.
4c. Testing with WebAIM’s WAVE
WCAG enumerates a range of different levels of conformity for a web page. I believe that all web pages should conform to Level A where possible. It is very hard to achieve Level AAA conformance, so Level AA conformance would be a very good compromise. The WAVE (Web Accessibility Evaluation Tool) provided by WebAIM (Web Accessibility in Mind) is a great place to get a handle on where you need to sharpen your accessibility coding skills. It’s an on-line evaluation tool for single web pages.
The first time you run a test using the WebAIM evaluator will probably give you a shock but by stepping through the results you should be able to see what sort of issues you may have to address. There’s a neat summary that the tool provides:
You can use this summary interactively to drill-down to each individual issue where explanations are given in fine detail, along with links to external documentation. As a rule of thumb I aim for - and don’t usually achieve - 0 red errors and 0 yellow alerts on any single page. When these show up as anything other than zero, then I can probably fix it by going back into the page’s code. It looks worse - and more frightening - than it is, particularly because it lists things that you have got right as well as those you haven’t. But this is probably the best free accessibility evaluation tool out there. As with the W3C validator, template-based issues may be identified which - when fixed - will apply across your site.
4d. Testing with AChecker
An alternative accessibility evaluation tool is AChecker.
Make sure you click the Options link so that you can specify which guidelines to check against. Start with the WCAG 2.0 (Level AA) option, and check the Show Source and View by Guideline options. When the results appear, you can check the various categories of issues shown under the available tabs:
If you have opted for the WCAG 2.0 (Level AA) check, you should be aiming for 0 known problems and 0 likely problems. The impossibly long list of potential problems is for your study purposes!
Wrapping up
Your journey towards building ‘accessibility-compliant’ websites can’t be swift and not just because such compliance is defined on a variety of levels. You can, however, take heart that some extremely valuable resources are available and there are real experts out there who are willing to share their expertise. (Take a bow, please, Laura Kalbag!) Running some of the pages you’ve already built through, for example, the last two evaluation tools on this list should give you a clear idea of what you might like to set your sights on.
Why not jump right in and get the WAVE browser extension for Firefox or the WAVE browser extension for Chrome and start checking over your own work from now on?
[February 2021 note: my attention has been directed to an in-depth guide on website accessibility: Website Accessibility Made Easy: Your 2021 Ultimate Guide. Thanks to Virginia Lameda for this recommendation. The page in question is as comprehensive as one can get.]