Accessibility is a difficult challenge at the best of times. The best way to include accessibility in a website or app is to start with design. This talk goes over five tips for designers (and for the people who work with them) to get started in incorporating accessibility into their work.
4. WHAT TO THINK ABOUT
Images
Audio and video
Icons
Colors
Visual cues
Headings
Landmarks
Skip links
Keyboard focus
Information architecture
Navigation
ConsistencyReadability
Reading order
Links
Typography
Data tables
Forms
Custom controls
Error prevention
Dynamic content
Touch
Lots of stuff.
Session timeouts
Valid code
Duplicate IDs
Programmatic association
Keyboard operability
Screen reader compatibility
Name, role, value
Pause, stop, hide
Links vs buttons
Error association
5. WHAT TO ACTUALLY THINK ABOUT
Usability
Users
Teamwork
Tricky Parts
Patterns
6. KEY #1: Understand Usability
Ask:
Is it usable?
Then you’re halfway there already.
9. NIELSEN’S 10 HEURISTICS
1. Visibility of system status
2. Match between system
and real world
3. User control and freedom
4. Error prevention
5. Help users recognize,
diagnose, and recover
from errors
6. Consistency and standards
7. Recognition over recall
8. Flexibility and efficiency
of use
9. Aesthetic and minimalist
design
10. Help and documentation
10. KEY #2: Understand Your Users
Everyone is disabled at some point in their lives.
12. WEAR THEIR SHOES
Simulating disabilities
Work outside on a sunny day
Ditch the mouse, use a keyboard
Test with your mother
NoCoffee extension
14. KEY #3: Work With Your Team
Product Manager
Researcher
Designer
Content Creator
Developer
QA
15. DESIGN COST
Scope Prototype Build Ship
State of
Design
Ideas Wireframes,
prototypes
Product under
development
Product
released to
public
Effort Very low effort
to change
Low effort to
change
Medium-high
effort to change
Very high effort
to change
SHIFT LEFT
how to be effective as a designer.
Talk is geared primarily towards designers
Understanding how design fits into accessibility is important for all roles, I think
In the audience:
who’s a designer?
who’s new to accessibility?
I’ve been in UX almost 6 years, if you count schooling. Graduated 2013 from School of Information at U-M
Only been working specifically in accessibility for 2 years (but had exposure before, b/c worked at U-M)
Intro to Deque: accessibility products, services and training, mostly for large companies. Also have open source tools, which Matt will talk about coming up next.
What I do at Deque: work on product team designing a product to help development teams do their own accessibility testing
our products are accessible, because duh
I also do research: part of my job is to understand how accessibility fits into development lifecycle and how people learn about accessibility so they can use our tools
There’s a lot to know in the field of accessibility – it’s not easy.
Lots of topics, lots of nuance, lots of requirements.
Covers lots of areas – visual design, information architecture, code quality, etc.
It was overwhelming to me at first.
If getting started, should go bit by bit. Don’t try and tackle everything at once.
5 concepts to start with – keep these in mind and it’ll help you build a good framework for learning and practicing accessible design.
Hopefully these concepts will build on the knowledge and experience you already have!
This is where you shine as a designer in terms of helping whatever your working on become accessible.
You know usability principles.
That’s seriously half the battle.
If you don’t know usability principles, make an effort to learn!
A falsehood you may encounter: accessibility and usability are almost entirely different things
This is how a lot of accessibility experts perceive the world
Why?
accessibility = different kinds of technology
usability doesn’t go far enough to support accessibility needs
lack of understand of what usability is
I disagree with them. Here’s how I perceive the world
There is a lot of overlap. Accessibility = subset of usability
a11y outside of usability – idea of ‘technical accessibility’ – a11y strictly according to specs.
usability outside of a11y – understanding user base and their needs and understanding that technical accessibility and user needs may be different
Concepts: inclusive design, universal design
If not familiar with these: 10 heuristics of usability, created by Jakob Nielson in the early 90s. Used to evaluate the usability of websites in particular
Pretty much all of these apply to accessibility. Most all of these show up as part of the WCAG guidelines
Main key with accessibility: have to take different user needs and different technologies into account. Can get more complicated.
Key to heuristics = understanding user’s needs and what does / doesn’t satisfy them
Key for accessibility – understand perspectives and needs of people who aren’t you. Understand how AT works, how people use it, what things affect different types of people. Part of designing for a specific user base.
Probably biggest struggle for people who don’t face disabilities in their personal lives – lack of understanding
You are not your user!
When recruiting users, try for 1 in 5 with a disability.
Goal: learn about how people with disabilities use the web and technology by seeing and doing.
Trickiest part can be finding people and coordinating tests. Tips for recruiting:
coworkers with disabilities, neighbors / friends, universities
start with interviews – easier to set up, and can learn a lot just by talking to people
Sometimes just can’t talk to users. The more you can look at and experience what you’re designing from other points of view, the better.
Typical roles on a design / user-focused development team
Everyone has different responsibilities, some overlap. But most likely you’re not the only one building a website, application, product, so can rely on teammates to help you
Key: empathy! Much easier to create usable sites / apps if team members care about usability. Same with accessibility!
Include team members in user research!!!!!
Goal should be to think about a11y as soon as possible!
Later in cycle = product and ideas more rigid
Learn and incorporate as much as you can while product is still flexible
Applies to design in general, but also to accessibility
The more thought about / incorporated sooner, the easier it will be later
That’s what I mean by shift left!
Very, very important to work together.
Designers: devs need to understand your design, you need to understand how it will be implemented. Annotate designs and talk it over with a dev or two!
Developers: understand design intent and who it effects: will help you make better decisions about how to implement
QA: needs to know what to test for and how to test it, put themselves in user’s shoes.
Communicating will help you to avoid time-consuming redesigns later
Also means: no one team member is solely responsible for accessibility.
These are all things that take extra consideration when designing and when implementing!
IN PARTICULAR – these are all things that you’ll probably want to design in conjunction with a developer. Communicate!
If you’ve had any experience designing and developing web forms, you probably know that they can be pretty complex.
First, labels!
Should be clear, concise, easy to find and read
Shouldn’t disappear when you start typing!
Help text should be clear and useful.
Rule of thumb: if you think people will have trouble filling out the field without help, provide help text!
(User testing can help you figure that out)
Errors – another way to help users.
User should know what went wrong and where, and error text should help them fix it.
How a screen reader works with tables: looks for headers
How it’s read out by screen readers: Rachel. Age. 28.
Note: data tables are my weak point; I don’t understand many of the technical aspects of making them accessible.
Key points:
Editable fields in tables. Labels? Errors? Interactions?
Icons – do they have labels? No header?
Of notes:
Multiple header rows. What’s most important?
Expandable areas
Checkboxes on right – what are they for?
Empty cells – how are they read to screen readers?
Some data in table-like columns, some not
Lots of interactive stuff
What is the user’s goal here, anyway?
TABLE KEYS:
Think about the information you have. Would it be better presented using something other than a table?
How can you simplify?
What’s the most important data that people need? What DON’T they need?
Complex tables = hard to make accessible, hard to make usable. So be careful
Custom control = anything that you can interact with that doesn’t use standard HTML elements.
Examples:
On left – uses html label and input elements
On right – uses paragraph tag for label and div tag for input – ‘contenteditable’ attribute so you can interact with it.
Both cases: CSS for styling. Can make them look exactly the same with CSS.
Why is this important?
keyboards, screen readers, etc. work best with standard control
lot more work to make non-standard controls accessible
What to do:
avoid using custom controls whenever possible
if you’re not sure developers know the difference, help them learn! Annotate designs, etc.
Sometimes you just can’t use a standard control.
Common example: calendar widget
Can design and build these things from scratch, and sometimes have to.
BUT FIRST – see what else is out there!
are there any accessible examples out there you can look at and either use or model something off it?
can the look of existing examples be easily changed, or no?
Keys to think about if you have to design and build your own:
how will someone go through it with a keyboard? What tab order would you expect?
What information would you want conveyed to a screen reader? For calendar widget – just the number is not enough. Convey which numbers are disabled, make it obvious what month it is, etc.
Initially: looks like a select box. Maybe has a dropdown of numbers
Next: Turns out it’s an interesting control thing that gives you lots of options. But how do you operate?
hit “minus” with 0 things, and it circles around to “8” (can’t book tickets for more than 8 things at a time)
add extra adults without adding anything else, and label continues to say ‘guests.’ Note label changes when multiple things are selected
nice that it gives more options then most. But what are the consequences? Do you get charged more for a pet? Maybe would be better off keeping it simpler for sake of comprehension
KEYS
start with something that already exists, if you can
test with users!
Dynamic content = stuff that updates / changes automatically when you interact with it. Without a page reload. Usually javascript, ajax
If stuff is changing, that needs to be brought to users’ attention.
What information does user need to know immediately in order to understand what is happening on the screen?
if nothing, don’t show it!
if information needed, need balance: don’t give too little or too much
Test with users!
A lot of stuff can be addressed up front by using a style guide or a pattern library for the application.
Especially helpful for trickier stuff, like forms, tables, custom controls (do it once)
Also a helpful communication tool for designers, devs, QA
Beware: requires maintenance! Can’t just set it and forget it
technology changes, patterns should too
Example 1 – accessible color combinations (for good color contrast)
Example 2 – form field, label, error message, icon, etc – all designed and coded accessibly.
Pattern library also has instructions for devs on how to programmatically associate error message text so that screen readers can find it
Really helpful for new designers and developers (or who are new to a11y)
Everything I talked about will help you:
know when to ask for help and who to ask
learn more about your users
give you easier ways to incorporate accessibility into your work
be a more effective designer