Design Before Code: Thinking About Accessibility from the Ground Up
- 4. CONTEXT: My Role
I am a UX designer.
I work on software which helps development teams
test their websites and apps for accessibility.
- 5. 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 compatability
Name, role, value
Pause, stop, hide
Links vs buttons
Error association
- 10. 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
Recognition over recall7.
Flexibility and efficiency
of use
8.
Aesthetic and minimalist
design
9.
Help and documentation10.
- 11. KEY #2: Understand Your Users
Note: Everyone is disabled at some point in their lives.
- 13. WEAR THEIR SHOES
Simulating disabilities
Work outside on a sunny day
Ditch the mouse, use a keyboard
Think like your mom (or test with her!)
NoCoffee extension
- 15. KEY #3: Work With Your Team
Product Manager
Researcher
Designer
Content Creator
Developer
QA
- 16. TEAM ROLES - ACCESSIBILITY
Scope
PM
Research
Prototype
PM
Designer
Content
(Developer)
(Research)
Build
PM
Developer
QA
(Designer)
(Research)
Ship
PM
QA
Developer
(Research)
- 17. 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
changeSHIFT LEFT
- 23. FORMS:
Does it look like a form?
Google Material Design - forms
Mailchimp pattern library - forms
- 27. TABLES:
Should it be
a table?
Example from oneworld’s Where We Fly tool;
screenshot featured in: Well Traveled Mile:
"Ultimate Guide to Booking American Airline
Awards: Part 2"
- 33. KEY #5: Style Guide / Pattern Library
Colors
Typography
Forms
Tables
Notifications
Icons
Content guidelines
Editor's Notes
- how to be effective as a designer.
Talk is geared primarily towards designers
Also a bit towards developers, esp. front-end developers
Understanding how design fits into accessibility is important for all roles, I think
- I’ve been in UX maybe 5 years
No disabilities - yet
- Company deals with digital accessibility (apps, websites, etc.) for Fortune 500 clients
Services – contracted by large companies to do accessibility assessments of existing sites / apps / etc. and help fix accessibility issues
Products – software for automated accessibility testing, and assistance with training and manual testing
Training – web-based courses, on-site accessibility training for clients
Lots of combined experience in accessibility
Mostly work with and market toward developers, since they’re the ones fixing accessibility problems
Emerging markets: designers, QA
Principle of Shift Left
- On surface, I do:
wireframes / mockups
user flows
visual design
user research
etc.
Note: I don’t do any coding (I have enough on my plate already)
1 of 2 designers, so I do a wide variety of stuff.
I also think a lot about accessibility
because software I work on revolves around accessibility, I know a lot about how it works
I’m particularly interested in designer’s role in accessibility
Note: specific focus on web
- Intro – topics I cover all based in WCAG (web content accessibility guidelines)
closest thing to ‘rules’ accessibility community has
1 – Images, audio, and video – alternative text. Probably most commonly thought of when people who don’t know much about accessibility think about accessibility
2 – Icons count as images, too – also usually need alt text
3 – Color: contrast. Information can’t be entirely visual
4 – Headings, landmarks, etc: Lots of different ways to navigate if you can’t see or can’t use a mouse – but only if site supports it.
5 – Consistency, organization: easy as possible for people to find what they’re looking for.
6 – Readability, etc: Once they find what they’re looking for, they need to be able to understand it!
7 – Forms, tables: More complex stuff, needs more thought – will talk about later
8 – Touch: don’t forget mobile!
9 – So yes, lots of stuff to think about.
10 – There’s lots more stuff that’s more developer-centric
- As a designer, you don’t need to know everything!
takes a long time to learn all this stuff
i’m not going to talk about nitty gritty, gonna talk more about mindset
Going to talk about things that will go a long way to help you add accessibility to your designs
usability – basic principles form groundwork for accessibility
users – understanding how people use things builds empathy
Teamwork – when creating a product, what’s designer’s role
tricky parts – know when to ask for help from developers
patterns – make it easier for you and others
- 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 many 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
- How I perceive the world
Usability overlap w/ accessibility (and vice versa) – there is a lot of overlap.
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. General principles. Pick out a few as examples:
Visibility of system status – give users feedback when the page changes state, etc.
comes into play w/ screen readers – if there’s a notification, make sure reading out the notification is prioritized for screen readers.
key here is understandability! make sure users understand what is happening. What information do they need to know for a change of state?
Error prevention
keep users from making errors, esp. with sensitive information
there are specific WCAG guidelines around this. For example, if submitting a form creates a financial transaction (thing ecommerce), WCAG states that users MUST be able to review everything they entered before submitting the form
Recognition over recall
- don’t make users work to hard! This is particularly important for users with cognitive disabilities
- 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
Why is inclusive design important? People to mention:
person broke their arm, can’t type fast (keyboard)
Using phone in the sun (glare = low vision)
no headphones, watching video in a café (subtitles)
distracted while using site / app (cognitive)
- When recruiting users, try for 1 in 5 with a disability.
For user interviews, for paper prototype testing, for card sorting, for usability testing on a finished product… whatever. The more you include different types of people with different types of abilities, the more you will understand.
Tips: anyone with a disability where you work?
Friends, family members?
Universities are good places to find people – check with the disability services department
- The more you can look at and experience what you’re designing from other points of view, the better.
Simulate disabilities when testing the design or the implementation.
Keep in mind – higher fidelity = easier to test design
But testing higher fidelity stuff can help you learn what to think about in lower fidelity work, like sketches and wireframes.
- Typical roles on a design / user-focused development team
Roles are pretty loosey-goosey, really depends on organization. Whole point is that you are not working alone (at least, you shouldn’t be!)
Everyone is contributing something a bit different
- Ideas and research
PM understands, prioritizes
Researcher includes users w/ disabilities
2. Wireframes / mockups
visual design accessibility
accessible content
info architecture
dev there to talk feasibility, including accessibility concerns in implementation
test w/ users w/ disabilities if possible
3. Getting stuff into code
implement designs with accessible code
set up tests for a11y features
hopefully keep testing with users
4. Ship the product
keep testing for bugs, with users
devs kept on for support
PM is there managing work and client relationships the whole time
Job of people in earlier steps: convey important info to people in later steps.
As designer, your role is to communicate important aspects of design to developers and QA people. Including accessibility!
Make note of accessibility features in annotations
- Later in cycle = product and ideas more rigidt
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.
My team – right now, 1 PM, 2.5 devs, 1 content, 1.5 QA. I rely on devs and content guy especially to give feedback on designs
1 dev and content guy are better at technical a11y than me
- 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.
- Lots of things to think about with forms, because forms have lots of interaction and lots of different states.
labels easy to read, present ALL THE TIME
no placeholders. Placeholders = bad contrast, disappear when you type
Label groups – extra context means easier to understand
bottom example from airline – what if user hasn’t flown before?
- Help text should be simple and useful
If bad data triggers and error, make sure user knows what kind of data to put in so they don’t get an error
Longer text, use a little tooltip. That’s cool.
make sure people can access it
- Simple error
shows up underneath field, hopefully read out properly by screen readers
red is used because red means error (at least in this country). But color might not be enough? add icon?
sure would be nice to know ahead of time if required
Complex error
“too short” on right side of first field – horrible contrast
“passwords must match” – icon in front for error isn’t color dependent
error for both fields, or just one of them?
beware triggering error too soon (I went back, then forward and got error)
- Google’s material design. Short text input, long text input (from Google Forms)
Is length enough to be able to tell one is a text area?
2. In comparison, check out standard-looking form fields. Easy to tell what you’re supposed to do with those fields.
Affordances
Familiarity
In general – lots of things to think about with forms
- 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.
- Should it be a table?
Stuff seems to be arranged in table-like fashion – departure airport, arrival airport, airline are all lined up.
One thing that looks like a table header – “Travel Dates” at the top
Lots of information in here. Looks a bit like small tables nested in large table, but each small table has extra information attached to it…
General takeaways with tables:
all examples I used can be made accessible… probably. Some with more work than others
test with users! test for understandability first. If they don’t know what info the table is trying to convey, probably need to redesign it.
sometimes it makes sense to break up a table into more than one
It never hurts to be obvious.
- Should it be a table?
Stuff seems to be arranged in table-like fashion – departure airport, arrival airport, airline are all lined up.
One thing that looks like a table header – “Travel Dates” at the top
Lots of information in here. Looks a bit like small tables nested in large table, but each small table has extra information attached to it…
General takeaways with tables:
all examples I used can be made accessible… probably. Some with more work than others
test with users! test for understandability first. If they don’t know what info the table is trying to convey, probably need to redesign it.
sometimes it makes sense to break up a table into more than one
It never hurts to be obvious.
- Should it be a table?
Stuff seems to be arranged in table-like fashion – departure airport, arrival airport, airline are all lined up.
One thing that looks like a table header – “Travel Dates” at the top
Lots of information in here. Looks a bit like small tables nested in large table, but each small table has extra information attached to it…
General takeaways with tables:
all examples I used can be made accessible… probably. Some with more work than others
test with users! test for understandability first. If they don’t know what info the table is trying to convey, probably need to redesign it.
sometimes it makes sense to break up a table into more than one
It never hurts to be obvious.
- 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
- Chimera = creature from greek mythology with lion for front, goat in middle, dragon or snake at back.
Custom control chimera – something that’s trying to do all the things
hard to make it understandable for the average user
hard to use without a mouse
Key: simplify as much as possible!
Designer: consider multiple options, test with users
Developer: if you know you can’t use a standard control to implement design, estimate more time to build it. Talk with designer and make sure they understand the consequences. It’s more work for you.
- Dynamic content = stuff that updates / changes automatically when you interact with it. Without a page reload. Usually javascript, ajax
Already touched on this, but if stuff is changing, that needs to be brought to users’ attention. Stuff to think about in this example:
Can users see changes?
Is it obvious which field the error message belongs to? Does it belong to both, or just one? What’s read out to screen reader users?
How important is this information? Does it need to be visible at all times? Does it need to be read to screen readers every time it changes?
In general: what information do people need so they understand what’s happening?
Usability testing here is VERY IMPORTANT
- A lot of stuff can be addressed up front by using a style guide or a pattern library for the application.
Note forms and tables in my list – can bake accessibility into patterns and give instructions for use
less work for developers, require less accessibility knowledge to use
less work for designers, cause can use same things over
consistency!!!
Pattern libraries = investment.
If your lucky, the place you work at will already have one that they’re using
- Addresses text accessibility – specifically color combinations
Probably part of a premade stylesheet
designers can specify text color they want by css selector
devs can easily implement
- Can specify a LOT of things about forms – label placement, error messages, icons, colors, etc.
see submenu on left
devs cut and paste most of code
some stuff still done by hand, provide instructions for implementation
see section on a11y at bottom
- 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