Usability and Accessibility Have a Conversation: How Accessibility and UI/UX Teams Can Collaborate for More Inclusive Products
•Transferir como PPTX, PDF•
1 gostou•1,706 visualizações
Starting with Jesse James Garrett's model of User Experience, this webinar will examine where accessibility and usability dovetail in areas such as user research, information architecture, persona, wireframes, visual design, and user testing. By understanding more about each other, we may better navigate each other's challenges and solve each other's problems more effectively.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Usability and Accessibility Have a Conversation: How Accessibility and UI/UX Teams Can Collaborate for More Inclusive Products
Semelhante a Usability and Accessibility Have a Conversation: How Accessibility and UI/UX Teams Can Collaborate for More Inclusive Products (20)
Mais de 3Play Media
Mais de 3Play Media (20)
Último
Último (20)
Usability and Accessibility Have a Conversation: How Accessibility and UI/UX Teams Can Collaborate for More Inclusive Products
- 1. Usability and Accessibility Have a Conversation: How Accessibility and UI/UX Teams Can Collaborate for More Inclusive Products Jiatyan Chen Online Accessibility Program Manager Stanford University www.3playmedia.co m Twitter: @3playmedia Live tweet: #a11y • Type questions in the window during the presentation • This webinar is being recorded & will be available for replay • To view live captions, please follow the link in the chat window Patrick Loftus (Moderator) Marketing Assistant 3Play Media
- 2. Accessibility Jiatyan Chen <jiatyan@stanford.edu> Stanford University Usability & Have a Conversation
- 3. Who? Program manager IT, Project manager UX, ID Producer, Developer The Design of Everyday Things by Donald Norman
- 7. Why? Usability and Accessibility have a lot of overlaps in topics but structured differently. Designs are handled as elements or whole, while WCAG is organised by principles. UX A11y
- 8. How? The Elements of User Experience by Jesse James Garrett.
- 9. 1. Strategy Purpose & goals Needs, both outside & inside Stakeholder meetings Market research Personae Success metrics
- 10. 1. Strategy - persona Description: 35, divorced, 2 young children, mid-level manager, wants promotion and pay raise Stresses: time to take classes & do homework, travelling, no spouse to tend to children, babysitter choice Needs: calendar, when to do tasks, choices of courses, what others chose
- 11. 1. Strategy - success metrics Unique users Time on site Traffic source Time on task Sales Brand impression Student grades Messaging perception Reduce help desk calls ...
- 12. 1. Strategy Purpose & goals Needs, both outside & inside - business case for accessibility? Stakeholder meetings - invisible stakeholders? Market research Personae - credible 'disability' characteristics. Need ideas? See A Web for Everyone Persona, An Alphabet of Accessibility Issues Success metrics - unique users, % reached, reduce errors, equivalent ease of use, standards violation, improve comprehension
- 13. 2. Scope Features and content. Functional specification aka "feature set" Task analysis, user interviews Put personae into scenarios Content inventory, content analysis Project charter Trade-off requirements vs feasibility of making them
- 14. 2. Scope - scenario (Scenarios): Which courses to enroll? How can I graduate? Deadlines? 2min on page
- 15. 2. Scope - content inventory
- 16. 2. Scope - content analysis combine
- 17. 2. Scope Features and content. Functional specification aka "feature set" - critical (vs optionals) to make accessible Task analysis, user interviews - happy path to make accessible Put personae into scenarios - situational disability, platform constraints in tasks Content inventory, content analysis - core content to make accessible Project charter - assumptions about time limits & capabilities, in scope vs out of scope Trade-off requirements vs feasibility of making them - refer
- 18. 3. Structure How product works Interaction sequences & responses (IxD) using standards, HCI guidelines, cognitive psychology Content structure & information relationship (IA) using card sort & data analytics Writing style guide
- 19. 3. Structure - interaction sequence Tech Support Cheat Sheet by xkcd
- 20. 3. Structure - interaction sequence
- 21. 3. Structure - information relationship A visual history of human knowledge by Manuel Lima
- 22. 3. Structure - information card sort
- 23. 3. Structure - card sort
- 24. 3. Structure - information site analytics
- 25. 3. Structure - IA
- 26. 3. Structure How product works. Interaction sequences & responses (IxD) using standards, HCI guidelines, cognitive psychology - use accessible pattern libraries eg. WAI-ARIA Authoring Practices, eBay MIND patterns, deep dive into non-standard elements Content structure & information relationship (IA) using card sort & data analytics - be intentional about hierarchy, sequencing, semantic structure, help/contact Writing style guide - taxonomy, keywords, title, link text
- 27. 3. Structure - taxonomy
- 28. 3. Structure - taxonomy
- 29. 3. Structure - taxonomy
- 30. 4. Skeleton Presentation for understanding and interaction. Wireframe, navigation/wayfinding UI controls, states, behaviours, error handling Prototype, test & refine with user testing Heuristic evaluation/expert review Code framework, platform & library
- 31. 4. Skeleton - wireframe
- 32. 4. Skeleton - wireframe
- 33. 4. Skeleton - paper test What is this page about?
- 34. 4. Skeleton - paper test Not related. Oops!
- 35. 4. Skeleton - Usability Heuristics 1. Visibility of system status 2. Match between system and the real world 3. User control and freedom 4. Consistency and standards 5. Error prevention 6. Recognition rather than recall 7. Flexibility and efficiency of use 8. Aesthetic and minimalist design 9. Help users recognize, diagnose, and recover from errors 10.Help and documentation
- 36. 4. Skeleton Presentation for understanding and interaction. Wireframe, navigation/wayfinding - annotated wireframes, read order, beware of cognitive load, UI controls, states, behaviours, error handling - keyboard, time limits, platforms differences Prototype, test & refine with user testing - AT testing, verbal walkthrough Heuristic evaluation/expert review - both usability and accessibility experts Code framework, platform & library - automated accessibility tools, use libraries which have a11y support, code to standards
- 37. 4. Skeleton - annotated wireframe
- 38. 4. Skeleton - annotated wireframe Early prevention of accessibility issues with mockup & wireframe reviews by Aidan Tierney
- 39. 4. Skeleton - verbal walkthrough Accessibility and Design — Where Productivity and Philosophy Meet by Ryan Strunk, Joe Lonsky
- 40. 4. Skeleton - Usability Heuristics 1. Visibility of system status 2. Match between system and the real world 3. User control and freedom 4. Consistency and standards 5. Error prevention 6. Recognition rather than recall 7. Flexibility and efficiency of use 8. Aesthetic and minimalist design 9. Help users recognize, diagnose, and recover from errors 10.Help and documentation
- 41. 5. Surface Sensory experience of finished product Design comps & style guide Colour palettes Imagery selection Branding & visual elements
- 42. 5. Surface - comps
- 43. 5. Surface Sensory experience of finished product Design comps & style guide - all situations & states, colour+, typography & layout for dyslexia & low cognitive load Colour palettes - colour contrast Imagery selection - suggested alt text Branding & visual elements - icons with labels
- 44. 5. Surface - style guide
- 45. 5. Surface - palette https://brand.berkeley.edu/colors/
- 46. 5. Surface - icons Endless Legend
- 47. 5. Surface - icons Endless Legend
- 48. 5. Surface - icons Endless Legend
- 49. 5. Surface - icons Endless Legend
- 50. 6. Sustain Continuous Delivery -> "Agile" feedback Sprints on limited features User Acceptance Test User feedback
- 51. Sustain - UAT
- 52. 6. Sustain Continuous Delivery -> "Agile" feedback Sprints on limited features - automated regression test, timeboxed manual test, test something every sprint User Acceptance Test - SR & keyboard test with UAT script, UAT for accessibility User feedback using questionnaire - periodic WCAG evaluation, prioritise accessibility requests
- 53. Sustain - Yahoo! A11y Lab Top 10 common issues "Don't let us find these!" 1. Missing or incorrect names 2. Navigation doesn't follow visual design 3. Skipping over visible items or speaking invisible items 4. Not grouping visually related elements 5. Element type (link, button, etc.) is missing or incorrect 6. The state of buttons is not described 7. Headings are missing or used inconsistently 8. Missing "hints" that provide context 9. Missing closed captions or caption controls 10.Low contrast
- 54. More? The Design of Everyday Things by Donald A. Norman The Elements of User Experience: User-Centered Design for the Web by Jesse James Garrett A Web for Everyone: Designing Accessible User Experiences by Sarah Horton and Whitney Quesenbery Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug 100 Things Every Designer Needs to Know about People by Susan M. Weinschenk https://www.usability.gov/ Many thanks to ATHEN & WebAIM mailing list, and A11y Slackers. Jiatyan Chen <jiatyan@stanford.edu> Stanford University https://goo.gl/zgVCN M
Notas do Editor
- Start with who and why, and get into the how.
- Higher Ed. Stanford Online Accessibility Program manager - consults on policy, services, projects, communications Web Accessibility Coordinator, IT manager, project manager, UX designer, instructional designer, build online courses and interactive learning modules. ~time when I first started building modules. The (Psychology) Design of Everyday Things by Donald Norman. He taught me that the problem is NOT the user. Not guilty for failing to use a product. Designer's job to communicate the Affordances, provide appropriate Feedback and Constrain the errors. (eg. The biggest dial on a stereo should control its primary function of making sound. Particularly when the user is distracted by, say, driving.) Usability (or the lack there of) has kept my interest since that book.
- So how do we approach usability? Moving across country with as little a possible. Pack an office + large 4-drawer filing cabinet into a bankers box.
- Bat joined me in one late night for recycling.
- Recycled a lot, but among the few I kept are 2 buttons. Usability buttons - think about users and give them f() they need. Reminder of user-centred design. User != mechanical monkeys pushing buttons perfectly every time, but rather == experience, state of mind, situation, ability It took Whitney Quesenbery, juggernaut in UX, to point out that Accessibility expands usability to include more abilities and situations. Still about the user. Which is why...
- We keep seeing the similar topics coming repeatedly. Just structured differently. Use different language and conceptual maps. UX use methods and heuristics, while WCAG has observable success criteria. UXer design UI by elements, while Accessibility evaluate experiences by separate behaviours. Purpose of this talk is to suggest a way for these 2 lenses to work closer together.
- Model by Jesse Garrett to hold ideas together. Ideas I've picked up and filed. And when you get more than a handful, you need a way to organise them. 5 layers, from abstract to concrete, with activities to produce information feeding the final product. Accessibility comes in really strong at the concrete & tangible product end but fades out around structure. Decisions made at these upper layers do not address the core and so a11y keeps being treated as 'fixes'. This model might helps you map out where it is easier to affect the specific change.
- Purpose & goals -> strategic/vision/mission document, learning objectives User needs are the goals for the site that come from outside our organization -- specifically from the people who will use our site. Balanced against our own objectives for the site. (eg. user needs to fill in form as as little effort as possible) (eg. business need to gather sufficient info sell product) Stakeholder meeting drawn from representatives of whoever product affects. Market research on whether there is indeed a need, competitions, other users Outcome is a close approximation of *a* user, with sufficient background story, characteristics, needs and challenges. => Persona. Clearer to design for a person than a "target audience" fuzzy, average, no-face to relate to. Another outcome are ways to measure the product's success
- (eg food safety busy mum) with 2 young children, looking for degree programme to gain promotion, needs flexible scheduling
- Google it - mostly commercial Higher Ed metrics are student success, admissions support
- So how do we integrate accessibility into these activities? Business case for accessibility - policy, financial, legal, social, technical Probe more for stakeholders My boss and I were called to a meeting at the university president's office one day. The chief of staff and the secretary of the Board told us that they want us to build a digital kiosk. It has to be outdoors, available to the public, and the user can browse through 10 pages of text and media, and yes, it has to be accessible. It was a complicated project involving landscaping, infrastructure, hardware, OS, software and content. We have to build an UI to sit in a weather-proof display which is sealed in a climate controlled casing -- no external I/O except for waving your hands in front of the monitor -- super locked-down security, no keyboard, no mouse, no joystick, no audio jack. We went to DSS with these limitation and they said it is preferable to have an alternative website so that blind users can use their regular AT to get the same info, rather than being forced to learn a new interface. And we designed and built what that in mind. Come demo day, the president herself showed up. She liked it, and then asked that we make it speak the controls and titles for the blind users, and add 100 pages. That totally changed the specs. And my mistake was that I assumed the chief of staff gave me all the information in the president's head. So, ask a few more questions. Persona is the 'average' target user with a story. And designers are encouraged to use ONE primary persona to stay focused. So you have to "average in" the disability story. Don't appear as a fringe case. Success metrics - % of population, equivalent multiple paths, improve comprehension of courses
- List of what you want it it do/to inform. Features and content. Task analysis/user interview -> features, scenarios Scenarios (eg. IT site for students reporting computer login failure) Type of content to include Project charter - why, how, assumptions, NOT building, responsibilities. Revisit Strategy. Negotiation and trade-offs
- Scenario applied to persona Jill only has 2~3 to read a page before she get interrupted -> structure, writing. Most important info first
- For content, make a list Figure out what you have to tell your user
- Combine them
- Critical functions to make accessible Try for making happy path accessible Critical -> prioritise, MVP with a11y built-in Jill's situational abilities (eg. noisy children, eg. spotty bandwidth, eg. 1h commute), role play scenario -> platform constraints into tasks (eg. report computer outage == limited/no computer) Charter - pay attention to assumptions about limits on time and capabilities, out of scope Refer to strategic goals to see if it is the right thing to trade-off. Line item for accessibility (point back if needs be).
- How the system behaves in response to the user, how the product works. The arrangement of content elements to facilitate human understanding. Document interaction sequences & errors. Standards and heuristics. Error handling and prevention. Document of content structure & information relationship/flow Formulate style guide for coordinated writers
- Familiar flowchart of sequence. Start and end, with decision points and procedures.
- Bespoke interface of a microbiology procedure called Rapid Strep Test. When you go to your doctor with a sore throat and they take a swab, this is the test they do to determine if you have strep throat. Every step and behaviour has to be detailed for every step of what to do with a swab and number of drips in the well.
- Content organisation Manuel Lima laid out 15 topologies of information mapping
- Card sort to inform structure, taxonomy, popularity
- Gets translate design specs
- site analytics (eg. popular path, drops)
- End up with information architecture doc
- Use pattern libraries, don't re-invent. Ever wonder how a MENU should behave when interacting with ENTER or SPACE keys? WAI-ARIA Authoring Practices already has a thorough answer. Only spend time on non-standard elements. Be intentional and spell out hierarchy & semantic structure. Help/contact/grievance info. In writing and documentation, decide on consistent terms and the format of title and link text.
- Reason for deciding on taxonomy. Open-sourced online learning platform Open edX. LMS presents course content.
- Banner, tabs menu, modules listing, buttons for paging, footer
- SR sees a different set pulled from the underlying code. Discovered this discrepancy when we are writing documentation for SR users. Call it "contentinfo" landmark or "footer", ffs
- What form that functionality will take. Presenting for understanding and interaction. Time for prototyping Expert review draft
- Can be a sketch & explain
- myBalsamiq detailed pages layout
- User managed to find 3 pieces of info on "what this page is about"
- … but couldn't tell that a large heading is related to a smaller indented heading. Design had positioned them too far apart.
- Usability heuristics to run through. Famous one by Nielsen.
- A11y loudest, examples from others Annotated wireframe Handle keyboard mappings. Detail out handle errors particularly with time limits
- Read order for content in multiple columns Call a button a button, a link a link
- Mark out headings and buttons, even "convey disable state" with Traveller buttons Number of travellers need to be announced every time user adds or subtract from it
- Joe designer, Ryan a11y specialist. Joe walks through the design elements and Ryan comments on information needed in the design Back button, search field, 3 tabs. Looks like the middle tab is selected. Ryan: "tell me which selected" and with experience, adds, "new section selected should remove old label." Even if you don't have an a11y specialist to bounce ideas, do a blind test and walkthrough verbally with a colleague. See if they understand the information you are presenting.
- Bring back slide of Usability Heuristics for expert review. Half of usability heuristics covers accessibility topics. #1 visibility of system status.
- The sensory experience created by the finished product. Senses: touch, hearing, vision, spoken. Design comps & style guide -> consistency, provide enough details to make smart decisions in the future Branding & pattern library/gallery -> explain use cases, limitations
- Layout, position of cards. Responsive
- Design comps detail all states Contrast Label images
- Eg menu. Selected, hover, link Dark and light background Hover effect: zoom and underline
- Vibrant to classic, heavy to light Each combination test for contrast
- (eg. meaning of icons) "Click <something> on the button
- This is the icon for click. Looks like the front of an igloo or a cave. Weird. Next tutorial.
- "Zoom in and out <another igloo> for a better overview." Couldn't zoom. No scroll bar, no drag and drop, no ctrl-drag, no keyboard arrows, no page up/down, no WASD, no cmd-+, no magnifying glass. Skip Next Few pages later, another task I was unable to perform. So I started flipping through the tutorial quickly and
- … and noticed the difference between these 'igloos'. Red on left and red in centre. And it finally hit me that it is the top half of a mouse! Why is this icon so unfamiliar to me? Because I use a Wacom pen. And it doesn't have a scroll wheel. So. Label your icons, and don't assume everyone use the same device.
- Added another layer because of engineering and new methods of product delivery Sprint are short development cycles of a couple of week focusing on prioritised list of deliverables UAT consist of a list of tests which the features have to pass User feedback using questionnaires to inform of new features
- UAT: test name, test step, test data, expected results, pass/fail. Long list.
- Automated first. Pick only the most important features to test, BUT include a11y testing EVERY sprint. So you might cover a11y for separate features. Run through UAT with keyboard and SR. Even have a final UAT focussing on a11y Periodic WCAG.
- Here's how Yahoo limits the demand on their a11y testers - by teaching the simpler tests to their developers
- So, I hope I have given you some ideas on how usability and accessibility can work together at every level. I'd be happy if you can walk away today with one thing you can implement. Link for this slide deck.