Accessibility for UX Designers III

Dec 13, 2012

Third and final part of notes from an Accessibility workshop with Derek Featherstone.

This is the third, and final post about the Accessibility for UX Designers workshop, that was part of the Inspire Conference here in Leiden. Here are some more notes that I took from the excellent workshop.

Notes from the workshop

  • Tip: <tabindex="0"> will allow something to be in focus, that does not necessarily mean that it is clickable. (If you hit TAB a few times then you will see that the code block in this paragraph will be highlighted using this method.

  • Tip: keep modal (type) windows on the same page, and use anchor tags to call them. For example:

1 <a href="#usingthissite">
2 ....
3 <h2 style="display:none">Help</h2>
4 <div id="usingthissite" tabindex="-1" />
5 <p>......</p>
6 </div>
  • You could then position the element in a modal type box when the anchor tag is activated. When the user navigates away, then the next tab would be the next element after the anchor. If it was called in from another page, then the tab order would be lost and you would be positioned back at the top of the page. Using the above method, it would also cover all bases. If CSS was disabled then you would see a Help section at the bottom of the page, so it would always be possible to see the information required. Manage the focus, and manage the injection point of information being called in.

  • Tip: Autosuggest is great for people with dyslexia, or have poor spelling. However it is technically tricky for people who aren’t using keyboards as their input device. For people who are using speech software, but have poor speech, then it could be an issue. You should always counterbalance this by allowing for an override. A user should always be able to choose what they want, and not be given what the autosuggest finds.

  • Lots of rules are contextual, you cannot program for every situation.

  • ^&$^&^!* CAPTCHA

  • Tip: The earlier in the process that you think of accessibility, the less the cost to implement.

  • Tip: Include people with functional needs into personas, consider a user who has these needs. You do not need to specifically describe the disability, but you should always describe the requirements, such as, John needs to use a keyboard to navigate the website.

  • Tip: When doing user research, or usability tests, then always consider focus groups and have walk-throughs with people with disabilities. Never run a test when the test is not ready. If you know the site has poor accessibility, then do not run the test until you feel it is ready. It will be an infuriating experience for the tester. Do the technical accessibility fixes first, and then do the testing.

  • Tip: In design, always consider the colours / iconography / visual language, and make sure the contrast works. A black mail icon on white background may look like a letter to users with low-vision. Whereas if this was a white icon on a green background, then it will be more apparent.

This has been a long list of notes, and thoughts, some I have expanded on and looked into further, and I already have a number of other posts lined up. I want to look at forms in more detail, maps, carousels. From my brief venture into learning how to be better at accessibility I know that I have learnt an awful lot, but I am also aware at how much further I need to go on this subject.

The final part of the workshop resulted in an interesting question, “Okay, we know it is great, we know it is important - how do we sell it to the boss?”, it was an interesting answer, which talked about device independence, fluidity, responsive design, cleaner code, SEO benefits, bandwidth savings, compliance reasons. Which all seem excellent reasons of course, but I think my focus has to be on the individual.

I said in the first post that I don’t know anybody with a disability, however I rather stupidly forgot that I actually have Multiple Sclerosis. I am (to date) very fortunate in the fact that I have got used to the aches and pains, and general issues, and I am fortunate because I don’t see myself as being disabled, or have serious motor / cognitive issues that could come with the illness.

But what about tomorrow?

What if I lost access to do the things that I take for granted now?

What if something happened to you?

Accessibility is really important, and as the people who help build the web, we have to ensure that people realise that - even if it is perhaps for a selfish reason, let us try to make the web better.