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.
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
8. Document it
• As the designer, you are making decisions.
• Document them.
• Do not let the developers improvise.
• CYA.
• Eventually you will get a design system, pattern library.
9.
10.
11. Design System
• Document all this for your custom widgets,
• Use this to build a 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.
12. 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.
14. 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.
17. 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.
18. Structure
• Identify:
• Headings,
• Lists,
• Data tables,
• Captions,
• Regions (banner, navigation, footer, main content).
• This allows a developer to map them to correct element.
22. 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.
24. 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.
25. 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).
27. 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
28. Color and Contrast
• WCAG 2.1 has broadened it,
• Typography,
• Icons and glyphs,
• Form elements, error messages,
placeholders,
• Hover, focus, selected states.
29. 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).
34. 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,
• Use plain language.
35. 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.
37. References
• How to design for accessibility
https://www.bbc.co.uk/gel/guidelines/how-to-design-for-
accessibility
• Inclusive Design Principles
https://inclusivedesignprinciples.org/
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.
Interactive elements must be at least 1cm × 1cm (0.4in × 0.4in) to support adequate selection time and prevent fat-finger errors.
https://www.nngroup.com/articles/touch-target-size/
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.
I should not need a lawyer or programmer to translate the screen. Cognitive overlap
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, …)