Design Before Code - Global Accessibility Awareness Day Edition
•Als PPTX, PDF herunterladen•
1 gefällt mir•266 views
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.
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Design Before Code - Global Accessibility Awareness Day Edition
Ähnlich wie Design Before Code - Global Accessibility Awareness Day Edition (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Design Before Code - Global Accessibility Awareness Day Edition
- 1. DESIGN BEFORE CODE Thinking About Accessibility from the Ground Up Caitlin Geier
- 2. CONTEXT: About Me UX Designer at Deque Systems Live in Ann Arbor, MI No disabilities………yet.
- 3. CONTEXT: My Role at Deque
- 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.
- 11. USER RESEARCH 15-20% of people have a disability
- 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
- 16. YOU ARE NOT A SILO
- 17. KEY #4: Understand the Tricky Bits Forms Tables Custom Controls Dynamic Content
- 18. FORMS: Labels Mailchimp pattern library - forms Blizzard's Battlenet sign-up form GOOD BAD
- 19. FORMS: Help Text Mailchimp pattern library - forms
- 20. FORMS: Errors Mailchimp pattern library - forms
- 22. TABLES: With form controls Example from: [citation needed]
- 23. TABLES: All of the headers! Smashing Magazine: Designer User Interfaces for Business Web Applications
- 24. TABLES: Should it be a table? Well Traveled Mile: "Ultimate Guide to Booking American Airline Awards: Part 2"
- 25. CUSTOM CONTROLS: What are they? Anything that doesn’t use standard HTML control elements.
- 26. CUSTOM CONTROLS Mailchimp pattern library - forms
- 27. CUSTOM CONTROLS Virgin America home page
- 28. DYNAMIC CONTENT Blizzard's Battlenet sign-up form
- 29. KEY #5: Style Guide / Pattern Library Colors Typography Forms Tables Notifications Icons Content guidelines
Hinweis der Redaktion
- 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