Where UX fails Accessibility : Alastair Campbell
•Download as PPTX, PDF•
8 likes•1,711 views
Video: https://youtu.be/NrD5MlYcAZ8 UX and accessibility go hand in hand, without a good UX process creating a usable product, no amount of work on accessibility will make it good for people with disabilities. You can think of UX as optimising for the majority, and accessibility and scaling out an interface for minorities, but where do those aims conflict? There are interfaces being created for “great UX” that are fundamentally inaccessible. Do they need to be? At each stage of design there are four questions I ask to ensure an interface is accessible. If you can build those into your process, you won’t get blindsided after launch.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Where UX fails Accessibility : Alastair Campbell
Similar to Where UX fails Accessibility : Alastair Campbell (20)
More from Nomensa
More from Nomensa (20)
Recently uploaded
Recently uploaded (20)
Where UX fails Accessibility : Alastair Campbell
- 1. Where UX fails accessibility Alastair Campbell
- 9. When to define? Requirements gathering & Planning Sketching / Wireframes / Prototype Visual design Implementation /coding Adding content QA / testing
- 10. Define accessibility early 0 7.5 15 22.5 0 7.5 15 22.5 30 37.5 Planning Sketching Visual design Coding Content QA / testing Checks Project Activity
- 11. The real failure Not thinking of accessibility during the design process
- 14. Using Personas?
- 15. Expert user (with a disability)
- 16. FOCUS GROUP OF EXPERTS Expert users?
- 17. Stick it on the backlog?
- 18. Design for each Disability? Vision Hearing Motor Cognitive
- 19. By Disability? Keyboard / switch Mouse / eye tracking Speech recognition Magnification Colour/contrast adjustments Audio output Screen reader Vision Hearing Motor Cognitive
- 20. By Disability? Vision Hearing Motor Cognitive Keyboard / switch Mouse / eye tracking Speech recognition Magnification Colour/contrast adjustments Audio output Screen reader
- 21. By interaction method • Keyboard only • Screen magnification • Screen reader • Cognitive & Deafness
- 22. Keyboard only
- 23. iPod iPad iPhone
- 26. Interaction effects • Linear interaction, link by link • Lots of key-presses • Visuals important
- 27. Default Zoomed Magnified Screen magnification
- 31. Interaction effects • In a non-responsive design, you get horizontal scrolling. • Mainly about layout issues/bugs • Good contrast on text helps • Very ‘mouse’ driven • Field of attention small
- 32. Screen readers
- 34. Hidden structure To convey your structure, you need to understand when to use: • Headings (levels 1-6), Lists, Tables • Landmarks (“ARIA roles”) • Some HTML5, e.g. <section> • ARIA roles, states & properties for JS widgets ARIA = Accessible Rich Internet Applications from the W3C
- 35. Interaction effects • Linear interaction, line at a time in source order • Headings, landmarks, and find-text to skim read • Can use hidden support text • Depends on learned keyboard commands
- 39. Interaction effects • Choosing links that might be right, not knowing • Getting stuck on literal interpretations • Looking for help and alternative options
- 40. The four questions • Can you use it with a keyboard? • Can you see it when zoomed? • Does it provide appropriate information to screen readers? • Is it easy to understand?
- 44. Visual design
- 47. Implementation • Test as you build, it is everyone’s responsibility • Go through the 4 interaction styles for each component / build stage • Automated testing can be useful for catching some issues Implementation
- 49. Automated testing alt = “Dog”
- 53. Skip links
- 54. Skip links
- 56. • Can you use it with a keyboard? • Can you see it when zoomed? • Does it provide appropriate information to screen readers? • Is it easy to understand?
- 57. Questions?
Editor's Notes
- Problem: Most sites and applications are not accessible. Compared to when I started in the industry, it is a lot harder to find obvious examples of un-usable websites, UX has had a great influence and UX problems now tend to be the less obvious, harder ones. However, there doesn't seem to have been the same effect for accessibility, if you pick a random site it generally takes a few seconds to find accessibility issues. We are failing to create inclusive websites and digital products, and I think it is mostly because it is left to late in the process.
- UX for the general practice, but you could see accessibility as usability for particular audiences. You also need to understand: Web standards to known who’s fault something is. Access tech to know how people use your thing. UX and accessibility go hand in hand, without a good UX process creating a usable product, no amount of work on accessibility will make it good for people with disabilities.
- You can think of UX as optimising for the majority, and accessibility as making the interface robust. But, there are interfaces being created for “great UX” that are fundamentally inaccessible. Do they need to be?
- Imagine you can’t use a mouse, tabbing through the web. You want to get to an item on the right hand menu. Infinite scroll.
- This is an example where I can image the conversation was something like: We fly, let’s make the interface like flying through the clouds! This is happening on SCROLL.
- But now, imagine you can’t see that well. Here, I’ll blur it to simulate that. So people with this level of vision are likely to use a screen magnifier, which basically zooms into part of the screen. You then move your mouse around to move your view.
- So I follow the instructions, and scroll. And the whole thing becomes incredibly confusing! I actually gave up at the end, I couldn’t work out what was supposed to happen… See also adrianroselli.com/2014/05/so-you-think-you-built-good-infinite.html
- These are issues that are conceptually inaccessible, and are obvious from the outset to accessibility experts. But how do non-experts avoid creating accessibility nightmares? The first thing is when should you consider accessibility.
- Most projects have similar stages, or at least activities where you go from lo-fi to hi-fi and coding. Works with intro to accessibility and the guidelines. exercise: when each accessibility check could first be defined or tested. For example, you could check that the navigation is consistently placed from the first wireframes.
- There was wide variation in teams for who does what, but consistently 60-75% of the requirements, they thought, could be defined before coding. We all know it is better to catch UX issues as early as possible, the same goes for accessibility.
- The real way that UX fails accessibility, is by not including it during the design The impact is either: Accessibility issues Development time is increased E.g. an interactive feature is not covered by the developers accessible framework. When you are designing, sketching, whatever, how to you apply accessibility thinking?
- The first answer is often to use guidelines or checklists. Unfortunately that generally leads to a technical approach and leaves it too late in the process. The result is often bolt-on accessibility.
- For example, tick some boxes and test with a screen reader - not an elegant solution.
- Personas best when for tasks, goals, and motivations. People with disabilities tend to have the same tasks… But it simply doesn’t scale, you would need another 4 personas per persona.
- You could invite an expert user, e.g. someone who uses a screen reader.
- But again it is impractical to get coverage, you would end up with a focus group of experts. Also, that’s what the standards are for, to balance the different needs.
- If it goes into the backlog, by the time you get to it, the key decisions have been made. It is then cost-prohibitive to change it. Being ‘accessible’ is a quality measure. It is an attribute of every feature, it doesn’t work as a separate thing.
- How do I design for…?
- Boiled, simmered, reduced to… For each of these, I will give a quick overview.
- Many assistive technologies work as keyboard-access, even the most basic type, the switch. Stephen Hawkings is probably the most famous switch-user, but keyboard style input is useful for lots of people, such as those with: Tremors (due to parkinsons) Lack of fine motor-skills Painful movement (due to arthritis) Commons picture of Stephen Hawking: http://en.wikipedia.org/wiki/Augmentative_and_alternative_communication
- Although Hawking has his own custom setup, it is now mainstream. Since iOS 7 you can hook up iPhones and iPads to a bluetooth switch and it is supported just by updating the settings. This little demo shows how it appears on an iPhone, it works like tabbing through the screen and hitting enter, then it shows various actions you can take. Keyboard access also equates closely to voice input such as Dragon Naturally Speaking, and simply people who like/prefer to use a keyboard when possible. (Video credit Christopher Hills: http://www.youtube.com/user/icdhills/videos)
- There is a very simple way to try this yourself. Tab. Tab forward, shift tab to reverse, press enter for links.
- Here, I use the tab key to progress through the page, shift-tab to reverse, enter to follow links. Notice how Chrome adds a blue outline to the keyboard ‘focus’ point. The BBC ensured that mouse-overs are triggered by the keyboard as well. You can use the carousel controls. And cntl-f / cmd-f to find a link, which is similar to how voice recognition software works.
- Must be able to use everything (equivalence) Must have a visible keyboard-focus Skip links are very useful Can tell how to interact with menus/controls, and understand the sequence
- There are two main ways of making things bigger: Browser zoom (in the middle) is now the default across desktop browsers, and essentially makes the pixels bigger. Therefore in a responsive site the media queries trigger and you don’t get horizontal scrolling. - Magnification equates to a magnifying glass, where the site stays the same but your view is magnified. Imagine looking through a kitchen roll tube at your screen, you can only see a bit at a time.
- If we take a somewhat old fashioned design, non-responsive. Imagine you can’t see that well. To help, lets simulate that. (click) It isn’t too bad, but most of the text is not readable at this size. The default ‘make things bigger’ control in desktop browsers is zoom, so let’s try that. (click) It becomes readable, but we’ve lost the right hand side. When reading articles, you can get sea sick scrolling back and forward! Also notice that the contrast of text on its background is important, orange on white isn’t nearly as readable as black on white.
- Imagine you can’t see to well. I’ll help. But you can push it even further, and it starts using what you might consider the mobile view, and with good contrast, this is super-readable. Browser zoom basically makes pixels bigger, so a 1000px wide screen at 200% is effectively 500px. Also, using real text rather than graphics of text keeps it clear at high zoom levels, which really helps as well. So, responsive web design (or as Jeremy Keith would say “web design”) is a win for accessibility. Even better, you are probably already ‘testing’ for zoom, just by testing on mobile devices.
- A lot of sites now have seen this as a usability issue in general (see the “Locus of attention”), and John Lewis is a decent example of showing a reaction close to where you are looking. Here, it pops up a box right next to the button. Also, imagine I now want to buy some jeans, let’s try the menu at the top. It is really easy to loose your place, and also, to get lost in pop-overs. So for zoom & magnification, good web practices will get you a long way. Test your layouts, check the contrast, and watch out for how a narrow focus might affect your interactions.
- Keep changes close to the user’s action Test layouts for browser zoom at 200% Watch for large areas of white space Use text rather than images of text Check for contrast & background images
- Screen readers extend the keyboard access interactions with non-visual output. Not always audio, this is a braille display with keyboard, sitting on top of a windows laptop running JAWs. Like keyboard access it is a very linear interaction, going through the content one item at a time in source-code order.
- Obviously, this is a linear interaction, going through in source code order, like with keyboard access. However, because it’s assumed you can’t see the screen, the content is read out as well. In fact, a lot of meta-data around the content is read out, to convey the meaning of the HMTL and design. (click) In this example page, I can step through the page one item at a time, or ARIA-landmarks can be called up and navigated to, allowing me to explore the page quickly. - Heading are announced, and I can skim by heading. - Images with alt text describe their contents. - Properly marked up tables will remind me about the cell headings. - An tab widget with ARIA markup will tell me what it is, and which tab is active. NB: I have the ‘verbosity’ at the default, people used to a screen reader often turn that down so less is read out.
- So for the hidden side of accessibility, your markup (and scripting) is key. It doesn’t matter if you’re creating the most dynamically scripted page in the world, the basics are still important. Also, don’t worry if using a screen reader is a bit daunting. You can highlight these things just using the web developer toolbar.
- Must have alternatives for non-text items Audio shouldn’t play automatically Design should be represented in structure & metadata Headings, titles & link text should make sense out of context Use ‘standard’ form controls whenever possible
- This is a rather wide a vaguely defined group that does not (generally) use technology to help. Cognitive issues describe everything from dyslexia, learning disabilities, being on the autistic spectrum, to more esoteric issues like “mistaking your wife for a hat” (see the book). I group deafness here because the issues that come up (past not being able to hear) are due to language. If you are born deaf, your primary language is sign language, which has a different vocabulary and structure compared to English. Also, education for deaf children was not at all good until recently, quite a few deaf people over (roughly) 40 have very limited reading skills through no fault of their own. So this group is really about understanding the interface with limited reading skills. The effect I’ve seen in testing is often that people don’t understand the terms, it is like this signpost with meaningless labels.
- Using plain English is the best thing you can do, but to take it a step further, how much do you need to rely on language? Something I would try is to ‘greek’ (or in this case Russian) the text. Something you don’t understand. This really helps you to assume you can’t read. Notice how you could still get through to email, see stocks, and change the language. This is where iconography and imagery really help. For the prime content here, the stories, they associate both text and images for maximum understanding.
- Conventions Plain english (for everyone) Simplicity & focus are critical Adding relevant images & video useful (visual labelling) Clear boundaries, clear hierarchy Don’t enforce timing Flashing/moving objects an issue
- So there are really four questions you can ask at each stage of design & development. I have a checklist of all the points that covers WCAG 2 at AA level, but those are the four big questions from an interaction point of view. So early can we check these?
- Most of the accessibility requirements can be checked or defined at this stage, Thinking through our 4 questions, what can you spot?
- Keyboard You'll need keyboard controls for the drop-downs and carousel, possibly the play button as well. Will the focus of the keyboard be managed when activating the lightbox? Magnification: - Effects of user-action close to mouse focus Screen reader: Alt text for the carousel images / links, can you tell what the - Talking head probably doesn’t need audio description Video shouldn’t be auto-played Ordering of the headings, if you design it mobile-first / responsive, then you’ll have to make sure the content follows the heading. However, if not then often the headings would be implemented as a row. Cog/Deafness - Captions needed - Movements are under user-control, needs a pause/play button.
- When you have a sketch, wireframe or whatever, ‘Mark it up’ using the main structural elements: - ARIA landmarks (banner, main, search, ContentInfo) - HTML4 elements: H1 - H3, lists, tables Also, put down the assumed order for keyboard navigation. Not using tabindex, but what the source-code order is thought to be.
- If this visual design is a deliverable to clients or stakeholders, you really don’t want to be changing an approved design. We really want to avoid updating the navigation, link labels, or colours, make sure the accessibility is checked before it is distributes. Check for contrast first,
- There are many tools, I’m a little old fashioned for liking this one, but it only a few work on JPEGs or mock-ups.
- Secondly, make sure you design in the skip links and focus styles. Worst case, ensure that the focus styles match the hover styles (assuming they change).
- By the time we get to implementation, there should be almost no new accessibility requirements. Only a couple of things like keyboard traps and the code for form labels will be completely new. However, this is the stage where the rubber hits the road, all your planning needs to be implemented and tested. As you build: Does it work with the keyboard? Does it work with zoom? Does it work with a screen reader? It is understandable & consistent?
- Depending on your setup, you might be able to build in an automated testing using an API like WAVE or Tenon. However, few accessibility issues are fully automatable, it does not replace testing in a browser. You can test for failure, but you can’t test for success, in many cases appropriateness. I can prove that very simply.
- No automated test would catch this. If you use an automated tool, be prepared to configure it a lot, to work for your site. Picture: https://www.flickr.com/photos/malfet/1413379559/
- But you shouldn’t just hand it over to content authors and hope they can produce accessible content. Prevention beats cure, so if you use a WYSIWYG editor, please, please customise it. Take out the buttons that create inline styles, BUT, enable custom styles that work with your design. TinyMCE uses the style drop-down for that, that adds classes. For adding images, make sure the interface supports, preferably requires alt text. If it does video, does it prompt for captions?
- If the people adding content to the site are the same people designing and developing it then job done, but often there are people dedicated to content. As part of their introduction to the CMS, does that training include how to add alt text, and what good alt text is? The same goes for video content, do they know how to add captions? Do they know how to create the appropriate headings? This should be built into the editing system as much as possible, but some knowledge is needed. Also, is there an editorial process or workflow for checking ease of understanding, i.e. plain english?
- These steps with built in wheelchair access make for a nice metaphor about building accessibility in from the start. Apparently they have safety issues in the real world, but it still makes for a good metaphor. In the digital space you generally shouldn’t notice when a site is accessible any more than a usable one. However I can finish with a simple example.
- Skip links are… Often this is left to developers to cram in where they can. (BT example) You tab through the page and find a small blue link crammed into a little space in the layout. However, skips links are often used by people who can see the screen, so a skip link that is hidden needs to be really obvious when it pops up. Ideally it should also match the site’s design. (Nomensa example)
- This comes from thinking about it early in the process. From designing accessibility in. Most good examples of accessibility shouldn’t be things you see on the page, just like good UX.
- We know often the web sucks, and it generally sucks more for people with disabilities. Good designs create for the majority, great designs think about how everyone uses things. Please start thinking about accessibility as a quality of design issue, and see if you can answer these questions.