Where UX fails accessibility

Where UX fails accessibilityAlastair Campbell

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.

Digital AccessibilityWeb StandardsUXAccess technologies

UX for the general practice, but you could see accessibility as usability for particular audiences.

You also need to understand:Web standards to known whos 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.

Usable, but inaccessible?

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 cant 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, lets make the interface like flying through the clouds!

This is happening on SCROLL.

But now, imagine you cant see that well.

Here, Ill 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 couldnt work out what was supposed to happen

See also adrianroselli.com/2014/05/so-you-think-you-built-good-infinite.html

When to consider accessibility?

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.

When to define?

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.

Define accessibility early

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 failureNot thinking of accessibility during the design process

The real way that UX fails accessibility, is by not including it during the design

The impact is either:Accessibility issuesDevelopment 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?

Using guidelines?

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.

Using Personas?

Personas best when for tasks, goals, and motivations.

People with disabilities tend to have the same tasks

But it simply doesnt scale, you would need another 4 personas per persona.

Expert user (with a disability)

You could invite an expert user, e.g. someone who uses a screen reader.

Focus group of experts

Expert users?

But again it is impractical to get coverage, you would end up with a focus group of experts.

Also, thats what the standards are for, to balance the different needs.

Stick it on the backlog?

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 doesnt work as a separate thing.

Design for each Disability?VisionHearingMotorCognitive

How do I design for?

By Disability?Keyboard / switchMouse / eye trackingSpeech recognitionMagnificationColour/contrast adjustmentsAudio outputScreen reader

VisionHearingMotorCognitive

By Disability?

VisionHearingMotorCognitiveKeyboard / switchMouse / eye trackingSpeech recognitionMagnificationColour/contrast adjustmentsAudio outputScreen reader

By interaction methodKeyboard onlyScreen magnificationScreen readerCognitive & Deafness

Boiled, simmered, reduced to

For each of these, I will give a quick overview.

Keyboard only

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-skillsPainful movement (due to arthritis)

Commons picture of Stephen Hawking:http://en.wikipedia.org/wiki/Augmentative_and_alternative_communication

iPodiPadiPhone

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.

Interaction effectsLinear interaction, link by linkLots of key-pressesVisuals important

Must be able to use everything (equivalence)Must have a visible keyboard-focusSkip links are very usefulCan tell how to interact with menus/controls, and understand the sequence

DefaultZoomedMagnified

Screen magnification

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 dont 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 cant see that well. To help, lets simulate that. (click)It isnt 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 lets try that. (click)

It becomes readable, but weve 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 isnt nearly as readable as black on white.

Imagine you cant see to well.

Ill 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, lets 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.

Interaction effectsIn a non-responsive design, you get horizontal scrolling.Mainly about layout issues/bugsGood contrast on text helpsVery mouse drivenField of attention small

Keep changes close to the users actionTest layouts for browser zoom at 200%Watch for large areas of white spaceUse text rather than images of textCheck for contrast & background images

Screen readers

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 its assumed you cant 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.

Hidden structureTo convey your structure, you need to understand when to use:Headings (levels 1-6), Lists, TablesLandmarks (ARIA roles)Some HTML5, e.g. ARIA roles, states & properties for JS widgets

ARIA = Accessible Rich Internet Applications from the W3C

So for the hidden side of accessibility, your markup (and scripting) is key.

It doesnt matter if youre creating the most dynamically scripted page in the world, the basics are still important.

Also, dont worry if using a screen reader is a bit daunting.

You can highlight these things just using the web developer toolbar.

Interaction effectsLinear interaction, line at a time in source orderHeadings, landmarks, and find-text to skim readCan use hidden support textDepends on learned keyboard commands

Must have alternatives for non-text itemsAudio shouldnt play automaticallyDesign should be represented in structure & metadataHeadings, titles & link text should make sense out of contextUse standard form controls whenever possible

Cognitive & Deafness

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 Ive seen in testing is often that people dont 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 dont understand. This really helps you to assume you cant 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.

Interaction effectsChoosing links that might be right, not knowingGetting stuck on literal interpretationsLooking for help and alternative options

ConventionsPlain english (for everyone)Simplicity & focus are criticalAdding relevant images & video useful (visual labelling)Clear boundaries, clear hierarchyDont enforce timingFlashing/moving objects an issue

The four questionsCan 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?

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?

Sketches / Wireframes

Most of the accessibility requirements can be checked or defined at this stage,

Thinking through our 4 questions,

what can you spot?

KeyboardYou'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 doesnt need audio descriptionVideo shouldnt be auto-playedOrdering of the headings, if you design it mobile-first / responsive, then youll 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.

Visual design

If this visual design is a deliverable to clients or stakeholders, you really dont 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, Im 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).

ImplementationTest as you build, it is everyones responsibilityGo through the 4 interaction styles for each component / build stageAutomated testing can be useful for catching some issues

Implementation

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 cant test for success, in many cases appropriateness.

I can prove that very simply.

Automated testing

alt = Dog

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/

Prevention beats cure

But you shouldnt 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?

Elegant Accessibility

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 shouldnt notice when a site is accessible any more than a usable one. However I can finish with a simple example.

Skip links

Skip links areOften 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 sites design. (Nomensa example)

Skip links

This comes from thinking about it early in the process.

From designing accessibility in.

Most good examples of accessibility shouldnt 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.

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?

Questions?