Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

The Role of Design in Accessibility — a11yTO Meet-up

The Role of Design in Accessibility — a11yTO Meet-up

Herunterladen, um offline zu lesen

http://adrianroselli.com/2019/04/slides-the-role-of-design-in-accessibility-a11yto-meet-up.html
Designers can have an outsized impact on the accessibility of a project, being the ones who produce the visuals that are often critical for understanding and sign-off. Adrian will talk about the ways designers contribute to the overall accessibility of a site or application. We'll look at typography, structure, documentation, colour, contrast and more. Each of these has a corresponding WCAG SC to help provide guidance.

http://adrianroselli.com/2019/04/slides-the-role-of-design-in-accessibility-a11yto-meet-up.html
Designers can have an outsized impact on the accessibility of a project, being the ones who produce the visuals that are often critical for understanding and sign-off. Adrian will talk about the ways designers contribute to the overall accessibility of a site or application. We'll look at typography, structure, documentation, colour, contrast and more. Each of these has a corresponding WCAG SC to help provide guidance.

Weitere Verwandte Inhalte

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

The Role of Design in Accessibility — a11yTO Meet-up

  1. 1. The Role of Design in Accessibility
  2. 2. • I’ve written some stuff, • Member of W3C, • Building for the web since 1993, • Learn more at AdrianRoselli.com, • Avoid on Twitter @aardrian. About Adrian Roselli
  3. 3. WHERE DO I FIT?
  4. 4. WHERE DO I START?
  5. 5. Document it • As the designer, you are making decisions. • Document them. • Do not let the developers improvise. • CYA. • Eventually you will get a pattern library.
  6. 6. Pattern Library • Document all this for your custom widgets, • Use this to build a larger pattern library, • For many custom widgets: WAI-ARIA Authoring Practices 1.1, • It is not perfect, but gets you started, • Be wary of application-specific patterns. • For truly custom widgets you have never seen before, consider simplifying to an existing pattern.
  7. 7. Pattern Library 1. Title as <h2> which is also the link to the thing, 2. Image, but must appear below <h2> in DOM, 3. Plain text, 4. Share link.
  8. 8. HOW DO I DO IT?
  9. 9. Non-Text Content • When you include an image in a design, you do it for a reason. • Just a design element? • Support the narrative? • Stand-alone content? • You must account for its absence.
  10. 10. Non-Text Content • Hero images, • Background images, • Icons, • Video & audio, • Animations, • Charts, • Screen shots, • …
  11. 11. Non-Text Content http://www.4syllables.com.au/2010/12/text-alternatives-decision-tree/ https://www.w3.org/WAI/tutorials/images/decision-tree/ 1. What role does image play? 2. Does it present new info? 3. What type of info? Informative Yes alt="" or <a href="foo"><img alt="">Link</a> alt="" or Use CSS alt="descriptive identification" or alt="short label" + caption PurelyDecorative Sensory No alt="label for link" alt=“short alternative" or alt="short label" + caption alt="short label + location of long alternative" or long text alternative on same or linked page Long/Complex Short/Simple
  12. 12. Non-Text Content Alt: A unicorn with a rainbow mane and outstretched wings, clumsily stumbling around a clearing with a startled expression on its face.
  13. 13. Structure • Identify: • Headings, • Lists, • Data tables, • Captions, • Regions (banner, navigation, footer, main content). • This allows a developer to map them to correct element.
  14. 14. Structure Banner Navigation Related Search Footer Main content
  15. 15. Banner Navigation Related Search Footer Main content “Mobile” often means narrow screen in RWD, as well as this context. Structure
  16. 16. Structure
  17. 17. Sequence and Order • CSS techniques allow visual order to break from DOM order: • Floats, • Absolute positioning, • Flexbox, • Grid. • WCAG 1.3.2 and 2.4.3 describe meaningful sequence and tab order matching visual flow.
  18. 18. Sequence and Order
  19. 19. Typography • Avoid justified text, • Limit italics, • Use larger text (lean on browser default), • Use good contrast, • Avoid all-caps, • Avoid very long lines, • Use clear, concise writing.
  20. 20. Typography • Leading / line height at least 1.5× font size (WCAG 2.1), • Space after paragraphs at least 2× font size (WCAG 2.1), • Letter spacing / tracking at least 0.12× font size (WCAG 2.1), • Word spacing at least 0.16× font size (WCAG 2.1).
  21. 21. Typography
  22. 22. Color and Contrast • Does your thing rely on color alone to convey meaning? • Is there enough contrast? • Are hyperlinks, menus, etc. still visible? • WCAG 2.0: • 4.5:1 for normal text • 3:1 for large text (14+pt & bold, or 18+pt) • WCAG 2.1: • 3:1 for UI components, graphical objects
  23. 23. Color and Contrast • WCAG 2.1 has broadened it, • Typography, • Icons and glyphs, • Form elements, error messages, placeholders, • Hover, focus, selected states.
  24. 24. Hit Areas • Make areas large enough to tap, • Leave space between hit areas to avoid mis-taps/clicks, • Fitts’ Law (time to target as function of size of target), • Apple: 44pt × 44pt, • Microsoft: 48px × 48px (spaced 2mm apart), • Android: 48dp × 48dp (spaced 8dp apart), • BBC: 7mm × 7mm (inside an exclusion zone of at least 7mm × 7mm) • WCAG 2.1 Success Criterion 2.5.5 Target Size (AAA).
  25. 25. Hit Areas
  26. 26. Hit Areas
  27. 27. Hit Areas
  28. 28. Hit Areas
  29. 29. Instructions • Make sure hyperlinks have clear text, • Do not rely on instructions that assume a user can see, hear, or interact in a specific way, • Provide clear form labels, • Ensure errors are clear and direct the user to correct them.
  30. 30. Indicators • Make sure you have focus styles, • Do not rely on hover states for interaction, • Your design should indicate standard, select, hover, and focus states, • Remember that contrast requirements apply to all these, • Make sure errors, warnings, alerts do not get confused with regular content.
  31. 31. WRAP-UP
  32. 32. References • How to design for accessibility https://www.bbc.co.uk/gel/guidelines/how-to-design-for- accessibility • Inclusive Design Principles https://inclusivedesignprinciples.org/
  33. 33. The Role of Design in Accessibility

Hinweis der Redaktion

  • Accessibility is typically seen as a technical challenge in need of a technical solution.
  • A designer who is suddenly tasked with addressing accessibility may feel confused, alarmed, and all alone.

    Maybe even unable to contribute.

    But the designer is often the most potent force for accessibility on a team.
  • The WCAG 2 Quick Reference is a great tool to both justify that value and to push for a greater role in the process.
  • You can filter WCAG SCs based on just visual design and/or interaction design.
  • It may not be clear where you can start to have an impact.

    But there is always a good first step.
  • This also reinforces your value.

    Puts others in a position to accept, reject, challenge.

    Gives them the chance to get invested.
  • The BBC
  • Here the BBC team documents the content and structure of a screen.
  • https://www.bbc.co.uk/gel/guidelines/how-to-design-for-accessibility

    A pattern library would document things you re-use.
  • Now you need to know what to document.

    Let’s review some accessibility tasks that fall under the designer’s role.
  • It is unlikely you are taking random images off the web and dropping them into your design.
  • Non-text content comes in many forms.
  • Document the image and what its alt text should be.

    As the designer, you are the best one to do that.

    Remember that alt text for an image may be different when used in other contexts.
  • This can provide guidance to a developer.

    Avoids <div>-soup.

    Forces them, and you, to think about the content you are presenting.
  • It can be as simple as drawing boxes over your design.
  • Don’t forget that a responsive site can adjust its layout.
  • https://www.bbc.co.uk/gel/guidelines/how-to-design-for-accessibility

    A good structure allows AT users to quickly move to the content they want, or more easily explore the page.
  • It is too easy to rely on coding techniques that do not consider how the content is to be consumed.

    A keyboard-only user or screen reader user is going to consume and interact with the content in the order it appears in the DOM.
  • https://www.bbc.co.uk/gel/guidelines/how-to-design-for-accessibility

    A developer may not understand how you intend the content to be consumed.

    A developer may shoehorn it into a library or framework to make it look the same, regardless of flow.

    Note that for both reading order and tab order.
  • We can lean on long-established rules for good typography.

    Legibility benefits all users, but also helps those with cog, low vision, and folks traveling on bumpy planes or working in the sun.
  • WCAG also gives some guidance, but note that these are not hard rules.

    Instead, your design has to be able to adapt to this.
  • https://opendyslexic.org/about

    Specialized typefaces are generally ineffective.

    Note that Verdana and Helvetica are terrible anyway for not distinguishing between I and l.
  • We see this failure all the time

    I hate them because of all the screen shots I need for the audits
  • The screen shot is from the TPG style guide

    Note that it shows good color combinations and calls out ones to avoid
  • 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.
  • Apple
  • Microsoft
  • Android
  • BBC

    Not a platform; this is good for planning your own internal guidelines
  • Hyperlinks should manage expectations.

    Do not say “tap the red box to the right.”

    The form label should be visible, obvious, and not placeholder text.

    Error text should tell me what I did wrong, how I can fix it, and how to get to the errored field.
  • The easiest step is to duplicate your hover styles to your focus styles; document that step.

    Tool-tips are a no-no unless you can focus them and it is obvious; document the focus requirement. Make sure a user can dismiss tool-tips, similar with just an Esc

    A user should know what is the current thing, what has focus, what is disabled, and so on, with just a look. Calendar controls can have a dozen states (today, previous/next month, weekends, holidays, past, future, unavailable, selected date, selected current date, …)

×