Design Before Code: Thinking About Accessibility from the Ground Up
•Download as PPTX, PDF•
2 likes•281 views
Given at January 13, 2017 at Codemash (a developer conference in Sandusky, OH, USA)
Recommended
Recommended
More Related Content
What's hot
What's hot (11)
Similar to Design Before Code: Thinking About Accessibility from the Ground Up
Similar to Design Before Code: Thinking About Accessibility from the Ground Up (20)
Recently uploaded
Recently uploaded (20)
Design Before Code: Thinking About Accessibility from the Ground Up
- 1. DESIGN BEFORE CODE Thinking About Accessibility from the Ground Up Caitlin Geier
- 2. CONTEXT: About Me Live in Ann Arbor, MI UX Designer at Deque Systems No disabilities 2 cats
- 3. CONTEXT: Where I Work
- 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
- 6. WHAT TO ACTUALLY THINK ABOUT Usability Users Teamwork Tricky Parts Patterns
- 7. KEY #1: Understand Usability Ask: Is it usable? Then you’re halfway there already.
- 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.
- 12. USER RESEARCH 15-20% of people have a disability
- 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
- 18. YOU ARE NOT A SILO
- 19. KEY #4: Understand the Tricky Bits Forms Tables Custom Controls Dynamic Content
- 20. FORMS: Labels Mailchimp pattern library - forms Blizzard's Battlenet sign-up form Virgin America home page
- 21. FORMS: Help Text Mailchimp pattern library - forms Salesforces Lightning design system - forms
- 22. FORMS: Errors Mailchimp pattern library - Forms Blizzard's Battlenet sign-up form
- 23. FORMS: Does it look like a form? Google Material Design - forms Mailchimp pattern library - forms
- 25. TABLES: With form controls Example from: [citation needed]
- 26. TABLES: All of the headers! Example from: Smashing Magazine: Designer User Interfaces for Business Web Applications
- 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"
- 28. CUSTOM CONTROLS: What are they? Anything that doesn’t use standard HTML control elements.
- 29. CUSTOM CONTROLS Example from: Mailchimp pattern library - forms
- 30. CUSTOM CONTROLS Example from: Virgin America home page
- 31. CUSTOM CONTROLS = CHIMERAS? Encyclopedia Britannica: Chimera in Greek mythology
- 32. DYNAMIC CONTENT Blizzard's Battlenet sign-up form
- 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