Usability and Accessibility Have a Conversation: How Accessibility and UI/UX Teams Can Collaborate for More Inclusive Products

Editor's Notes

• #3: Start with who and why, and get into the how.
• #4: 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.
• #5: 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.
• #6: Bat joined me in one late night for recycling.
• #7: 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...
• #8: 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.
• #9: 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.
• #10: 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
• #11: (eg food safety busy mum) with 2 young children, looking for degree programme to gain promotion, needs flexible scheduling
• #12: Google it - mostly commercial Higher Ed metrics are student success, admissions support
• #13: 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
• #14: 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
• #15: Scenario applied to persona Jill only has 2~3 to read a page before she get interrupted -> structure, writing. Most important info first
• #16: For content, make a list Figure out what you have to tell your user
• #17: Combine them
• #18: 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).
• #19: 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
• #20: Familiar flowchart of sequence. Start and end, with decision points and procedures.
• #21: 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.
• #22: Content organisation Manuel Lima laid out 15 topologies of information mapping
• #23: Card sort to inform structure, taxonomy, popularity
• #24: Gets translate design specs
• #25: site analytics (eg. popular path, drops)
• #26: End up with information architecture doc
• #27: 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.
• #28: Reason for deciding on taxonomy. Open-sourced online learning platform Open edX. LMS presents course content.
• #29: Banner, tabs menu, modules listing, buttons for paging, footer
• #30: 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
• #31: What form that functionality will take. Presenting for understanding and interaction. Time for prototyping Expert review draft
• #32: Can be a sketch & explain
• #33: myBalsamiq detailed pages layout
• #34: User managed to find 3 pieces of info on "what this page is about"
• #35: … but couldn't tell that a large heading is related to a smaller indented heading. Design had positioned them too far apart.
• #36: Usability heuristics to run through. Famous one by Nielsen.
• #37: A11y loudest, examples from others Annotated wireframe Handle keyboard mappings. Detail out handle errors particularly with time limits
• #38: Read order for content in multiple columns Call a button a button, a link a link
• #39: 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
• #40: 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.
• #41: Bring back slide of Usability Heuristics for expert review. Half of usability heuristics covers accessibility topics. #1 visibility of system status.
• #42: 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
• #43: Layout, position of cards. Responsive
• #44: Design comps detail all states Contrast Label images
• #45: Eg menu. Selected, hover, link Dark and light background Hover effect: zoom and underline
• #46: Vibrant to classic, heavy to light Each combination test for contrast
• #47: (eg. meaning of icons) "Click <something> on the button
• #48: This is the icon for click. Looks like the front of an igloo or a cave. Weird. Next tutorial.
• #49: "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
• #50: … 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.
• #51: 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
• #52: UAT: test name, test step, test data, expected results, pass/fail. Long list.
• #53: 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.
• #54: Here's how Yahoo limits the demand on their a11y testers - by teaching the simpler tests to their developers
• #55: 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.