Hitting a contractible deliverable for accessibility is generally easy enough, even despite Drupal's best efforts to scupper all attempts with forms and redundant labels and other hidden gotchas. A deliverable in these cases usually comes in the form of meeting a standard, whether it be a North American client wanting Section 508 coverage, or A UK client wishing for AA coverage and protection from UK disciplinary against the Accessibility Acts laws. It’s these requirements that are commonly tested against some automated checker that gives you a nice happy ‘well done your site is accessible’ message. But the harsh truth is these automated tools look against pretty binary challenges; for however good they are, they will not perform logical tests or analysis. So lets don the Spock ears and look at accessibility from a logical point of view against some of the most common, annoying, yet challenge-passable errors your website will face.
ALT text
Simple test: do all inline images in your content have ALT text? The answer is probably yes, or at least it should be – and you can’t use the excuse that the content is client generated and they might miss the ALT text. At this point I'm assuming a certain degree of developer competency, that you know when to use an inline image and when a CSS background image is necessary. So all your images have ALT text, that’s great, then you’ll more than likely pass this test, but what we really need to know, in order to have a correctly accessible pass, is whether the ALT text actually benefits those that make use of it. To steal a quote from Wikipedia: “Alternative text allows the content and function of an image to be understood by text-only readers.” So go back to your page, find your ALT text, and read it to the person sat next to you. Now show them the image; does the ALT text actually provide the information that you see in the image? If not, then I’m afraid you’ve failed. Bad ALT text is arguabally worse then none at all, it just wastes time and nobody likes wasting time.
Link order and volume
If you ever get the chance, watch a visually-impared user - who is competent with a screen reader - navigate around the web; it is truly astonishing how quickly they can find whatever it is they are looking for. It's actually quite simple in practice: a dialog box of links is often their first port of call, loading all the available hyperlinks on a page in the order they are found, from the top down. So what? If I ask you how many links are on your page, chances are it's far more than you imagine, especially those loading within advanced 'mega nav' menu or dropdown navigation components. Priority links need to appear first, any content loading into dropdowns needs to be delivered logically, perhaps utilise some HTML5 technology with data attributes to bring this content in. The volume of links will stay the same unless you want to be really brave and ditch the drop-down all together, but what you have achieved is giving the links some degree of importance value.
Headers structure and order
Headers (h1, h2, etc.) are the single most important pieces of content on a webpage, yet the most abused and misused I come across. Pre-HTML5 a single h1 was the first piece of content a user would expect to focus on. From a styling point of view, it's obvious, assistive technology locates and presents this in a similiar way to the links dialog box discussed previously. But for assistive technology and logic in general, headers need to be hierarchial, even more so now that we can have multiple h1's correctly deployed within article sections of an HTML5 document.
The order is simple: an h2 is associated to its h1, an h3 to the h2, and so on down the stack. All too often headers are used to cheat styling, not providing useful structure to the content given to the user. Have a look at your webpage using a tool like the WAVE toolbar in FF, this will show you all headers. If you have floating h2's without an h1 in the same article or section, it needs changing. Assistive technology will not be able to correctly assess how important these are, so the user will therefore be equally confused. Makes sense, doesn't it?
Fieldsets, Labels and Legends
These I have to say are becoming more than a pet hate for me to put right, but it’s a simple case of understanding what they do.
The clue is in the name: a fieldset is a group of fields, or a set of fields, as the name suggests. We know a field is a partnership of a label and an input; in the same way a fieldset requires a legend, youcan't have one without the other - that'd be like having Ant and no Dec. The label is read with the input for assistive technology form components; if we add a fieldset and legend to the mix, then the technology would read the legend, then the label and input for each and every form component in the fieldset. This can get tedious if the fieldset is used to group fields instead instead of a header.
A common example of a fieldset would be one that groups ‘Personal Information’ of a user (first name, last name, dob, etc.) with a legend that states ‘Personal Information’. In this example a screen reader would read, “Personal Information, First Name, input, Personal Information, Last Name, input, Personal Information, dob input” and so on. The only real use of fieldsets and legends should be to contain radio and checkboxes, or fields like date and time, where the day month year values are separate inputs. So it makes sense for the legend to be read before each label and input. Use the title markers (h1, h2, h3 if necessary) to split the form up in the same way you would if it were a conventional article. Go back to the forms on your page and check the fieldset usage. Chances are it's hindering your accessibility approach by prolonging the time required to understand what information is covered by the form, and what needs to be completed.
Colour Usage
All too commonly we're blocked from meeting good accessibility standards before we've even started to code anything. A design will come through, look very shiny and polished, has responsive coverate, and is expertly annotated. But wait! What happens to focus or hover?
You change the blue colour used to highlight a link into a different blue from your corporate colour palet. Hmmmm, now our users that struggle with distinguishing a full colour palet will not notice that change. Ok, so the mouse icon changes from the arrow to the hand, that's great! But what about keyboard-only users? Thirdly, the excellent point you highlight in the sentence of an article using a red colour looks brilliant, but to users with difficulty distinguishing colour, the red looks the same as the black text colour. In these instances we have to get quite persistent with our client and reiterate that links that change blue on hover and focus need to have an underline added. This is called a 'change of state' so no matter what colours you see you'll notice the difference.
As a little tip here make sure your css covers: :hover, :focus, and :active pseudo elements. For important pieces of content in text: be a bit smarter with your syntax, move away from what is probably a span and a class. The easiest solution is to use bold or italics for featured content; strong and em are read much different in screen readers. Even the same bold / italic approach with a class that takes the font styling away from bold / italics back to the normal default will cover our bases.
Keyboard Traps
The last failsafe to check in our flying-stop tour of real world accessibility is the keyboard trap. Not all users use pointer devices like a mouse, and obviously mobile and tablet presentations of your page generally won’t either. Some users navigate exclusively with a keyboard, tabbing, or better still using the arrow cursors to move freely around a webpage. Chances are the more evolved your UI gets the more it relies on mouse interactions in its desktop view, so if something expands and contracts (accordions, mega navs etc.) make sure the trigger to open is the same as closing. There are loads of really useful keyboard safe scripts out to help an evolving UI play nicely with keyboard navigation. If your user can’t escape your top navigation, they will never find their way past your opening content, this will soon become too annoying and too stressful to continue and they move away. Again, the automated checklist of accessibility will not look for this, so you can't really say “Yes Mr or Ms Client, we’ve made your site truly accessible" until you can demonstrate this.
To conclude, I believe making your work accessible shouldn’t be a optional deliverable. We have a duty of care to the real world of users to build this in as part of our work, a lot of it is just good practice with your mark-up and CSS and the decisions you make when composing this. Finally, no mater how good automated test tools are for verifying your work, they won’t cover everything. It's best to ensure for your own pride and satisfaction that you review the work done against the points above, it’ll be quite embarrassing if you give the work your seal of accessibility approval only to be found out by real world users that it isn’t. To close, for those who do yield my observations, I take my hat off to you; together we are making the digital world a truly inclusive world.
Share this Blog with colleagues
