Prototyping Accessibility: Booster 2019

Editor's Notes

• #3: We will be doing group activities. This gets the chaos organization out of the way early. Have this slide showing as people come in.
• #10: 1980 definition: “In the context of health experience, a disability is any restriction or lack of ability (resulting from an impairment) to perform an activity in the manner or within the range considered normal for a human being.”
• #13: Everyone is different. No two people are alike. With that in mind, it only makes sense that not everyone's body is going work the way everyone else's. Because of this, some people might not be able to see, hear, speak, understand, or move the way other people do.
• #15: A blind user cannot see what is on their screen. This may seem obvious, but it's important to think about what this really means. Most users don't think twice about how they ingest or interact with the content on their screen, nor does it really matter what the underlying code looks like. This is not the case for someone who cannot see the screen. When looking at the screen is not an option, assistive technology (AT) such as a screen reader must be used to navigate the web. Screen readers rely on HTML to navigate. If the website or application is not properly coded, AT will not be able to pass along the correct information to the user. This includes such important elements such as: Most likely a keyboard only user Using a mouse is most likely difficult, if not impossible, for a user who cannot see what is on the screen. As a result, a user who is blind will most likely use a keyboard to navigate. A keyboard-only user requires all functions performed by a mouse to be actionable via keyboard. These users are also prone to keyboard and/or programmatic focus issues if their experience isn't managed properly.
• #16: Someone with low vision has an impairment that cannot be corrected. In many cases, the person may be "legally blind" but still have some visual perception. There are different kinds of low vision and each has its own considerations. These considerations are different from blindness, though there may be overlap in approaches.
• #17: Some people may not be able to hear at all, or may have some kind of hearing impairment. This means any cues or information that are communicated by sound alone may be missed. The following barriers can occur.
• #18: Someone with a speech disability may be able to speak less clearly than others, or perhaps be entirely non-verbal (and this could be due to physical/motor or cognitive challenges). Some factors to bear in mind are: Web-based services or functionality that require voice interactions will be difficult if not impossible Websites or applications that offer a phone number as the only way to communicate with a company A person who struggles with a speech impairment might use specialized AT, or none at all, depending on the root cause of their impairment. For example, someone who has lost their voice due to an injury or sickness might not require AT to navigate the web whereas someone who is non-verbal due to autism might require a screen reader or a more specialized application to communicate.
• #19: There are many possible forms of physical impairment, such as mobility or dexterity issues. When thinking about web accessibility, the most prominent physical impairments are motor control and the inability to use two hands at once, as these most affect interaction with a device.
• #20: Cognitive disabilities affect far more people than sensory disabilities. There's a large variety of reasons for cognitive barriers, and a corresponding wide range of effects they can have. Some causes and conditions are… Asperger's Syndrome Attention deficit disorder (AD/HD) Autism Dementia Down Syndrome Dyscalculia Dyslexia Learning disabilities Rett Syndrome Stroke Traumatic brain injury (TBI) Williams Syndrome In order to make sense of the many different cognitive barriers people could experience, and to help us address them, they can be categorized broadly as follows. Memory Problem solving Attention Reading, linguistic, verbal comprehension Math comprehension Visual comprehension
• #21: Beware of disability stereotypes It's very important that we do not generalize people when talking about then individual needs. No two people are alike. With that in mind, we must be certain that we avoid the following: Using oversimplified terminology such as: Vision, hearing, physical and cognitive impairments These types of impairments are not one size fits all, for example "Vision" could mean someone who is low vision, someone who is light sensitive, or someone who is completely blind Using Misleading terms like: Screen reader users Many people require a screen reader, for many different reasons Incorrect:e.g. "Accessibility users“ Accessibility isn't something we use, but rather something we can't use without.
• #22: Our inclusive design principles Recognize exclusion Exclusion happens when we solve problems using our own biases. As Microsoft designers, we seek out those exclusions, and use them as opportunities to create new ideas and inclusive designs. Learn from diversity Human beings are the real experts in adapting to diversity. Inclusive design puts people in the center from the very start of the process, and those fresh, diverse perspectives are the key to true insight. Solve for one, extend to many Everyone has abilities, and limits to those abilities. Designing for people with permanent disabilities actually results in designs that benefit people universally. Constraints are a beautiful thing.
• #35: Trying to check into your airline in a foreign country Keyboards, system in different language Great way to extend a trip
• #39: The objective is to get people to champion their disability type and think about where its needs and challenges intersect with others. It should prime them for the personas and user stories section to maybe write more aggregated stories.
• #51: Talk about the general benefits, citing SR users, SEO (ugh), bad connections. Do not dwell on the technical stuff; let it be just the background
• #52: With images
• #53: Without Call out the logo (useful alt), the nav (CSS BG), the giant kid photo (blank alt)
• #54: Again, background. Do not dwell on the items, Talk about typography as an art, how legibility benefits all users, but also helps those with cog, low vision, and folks traveling on bumpy planes
• #55: Animated GIF, ~2s cycle Specialized solutions generally aren’t so good Compare to resizing widgets
• #56: Link text warrants some thought Context, destination, purpose all matter
• #57: Please make them obvious Contrast is a real concern… which we will discuss
• #58: What here is the link? The photo? The title? The date? The abstract? Hopefully not all of them, as that would be confusing to a SR user It is not obvious.
• #59: WCAG 2.1 AAA: 44px Excludes: Equivalent: The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels; Inline: The target is in a sentence or block of text; User Agent Control: The size of the target is determined by the user agent and is not modified by the author; Essential: A particular presentation of the target is essential to the information being conveyed.
• #60: Apple
• #61: Microsoft
• #62: Android
• #63: BBC Not a platform; this is good for planning your own internal guidelines
• #64: We see this failure all the time I hate them because of all the screen shots I need for the audits
• #65: The screen shot is from the TPG style guide Note that it shows good color combinations and calls out ones to avoid
• #66: Essentially you want a screen reader user to know what field they just focused You want voice users to be able to focus fields by name
• #67: Note that larger hit area benefit
• #68: Video with audio This is 1:44, so maybe talk over it for a bit
• #69: These allow SR users to jump to a section They are valuable for a reader view As we move to voice interfaces, these are valuable for the parsing algorithms
• #74: Also helps screen reader users Also helps reader mode Also helps future Uis (voice)
• #79: Animated GIF
• #80: Power users Mobility impaired Screen reader users
• #81: Animated GIF
• #83: Animated GIF
• #84: Video with audio
• #86: Animated GIF You can style anything to look like anything, so do not get hung up on choosing based on _how_ it looks
• #88: Screen shot of a link with the blue Chrome focus ring on the blue background of the Chrome help page.
• #89: Animated GIF
• #94: Pattern as taken from the WAI Authoring Practices Guide