A mockup or wireframe review is an opportunity to identify interaction design elements which are not fully accessible and will require changes. It's also the best time to identify any items that will need additional requirements to avoid becoming accessibility defects later on. After demonstrating the technique we will practice on a sample mockup. You'll leave this session with skills to apply on your next sprint.

2. We can review accessibility at any stage
Contract/SOW Business
Requirements
Mockups &
Wireframes
Visual Design Copy deck Development
QA User testing
In Production
(audits,
complaints)

3. Purpose of reviewing mockups & wireframes
• Identify defects
– Will need to modify interface
• Identify requirements to avoid defects
• Reduce overall effort
– Less defects
– Quicker QA
– Quicker fixes
– Less last-minute panic

4. ACCESSIBILITY ISSUES ARE
PREDICTABLE

5. Across your accessibility testing, What
are the issues you almost always see?

6. The usual suspects
Alt text
missing or
inaccurate
Headings
missing or
inaccurate
Form labels
Error
presentment
where, when, how
Roles
tab set, button,
toggle
States
expanded/collapsed
selected, disabled
Audio, video,
animation
cannot be
stopped
Notifications &
updating
content

7. WHAT IS A WIREFRAME OR MOCKUP?

9. Before the design or the code

10. A website wireframe, also known as a page schematicor screen
blueprint, is a visual guide that represents the skeletal framework of a
website... The wireframe depicts the page layout or arrangement of the website’s
content, including interface elements and navigational systems,
and how they work together.
The wireframe usually lacks typographic style, color,
or graphics, since the main focus lies in functionality, behavior, and
priority of content.
In other words, it focuses on what a screen does, not
what it looks like.
Wireframes can be pencil drawings or sketches on a
whiteboard, or they can be produced by means of a broad array of free
or commercial softwareapplications. en.wikipedia.org/wiki/Website_wireframe

11. A blueprint or schematic

13. Annotations
# Accessibility
1.
2.
2.
3.
4.
5.
6.
7.
8.
9.

14. 4 types of annotations
• 3 relate to predicting & avoiding issues
• 1 relates to identifying actual issues that
require a change

15. Content
alt text, labels,
instructions
(off-screen & onscreen)
Development
patterns
Known or simple:
tabs, expand/collapse
Complex
development tasks
(do-able)
Not accessible as-is
We need to talk:
interface changes needed
(or an exemption)

16. Content
alt text, labels,
instructions
(off-screen & onscreen)
Development
patterns
Known or simple:
tabs, expand/collapse
Complex
development tasks
(do-able)
Not accessible as-is
We need to talk:
interface changes needed
(or an exemption)

17. # Accessibility
1. Needs alt text (e.g. "back")
2. No alt text needed for any
of the icons to the left of
inputs on this screen
3. No alt text needed for icon
4. No alt text needed
5. Needs hidden/off-screen
label (business to provide)
6. Needs hidden/off-screen
label (business to provide)
7. Needs hidden/off-screen
label (business to provide)
8. Add/subtract icons need alt
text
9. Needs hidden/off-screen
label (business to provide)

18. Off-screen & onscreen content
• Alt text for icons, images, charts
• Hidden label text
• New or revised onscreen content such as
expected data values, instructions or
required field messaging
• This content will go into the copy deck for
translation and approvals
• Keep in mind the wireframe is not a copy
deck and most of the words are placeholders

19. Content
alt text, labels,
instructions
(off-screen & onscreen)
Development
patterns
Known or simple:
tabs, expand/collapse
Complex
development tasks
(do-able)
Not accessible as-is
We need to talk:
interface changes needed
(or an exemption)

20. # Accessibility
1. Button
2. No alt text needed for any
of the icons to the left of
inputs on this screen
3. For screen reader whole
row should act as single
element. No alt text needed
for icon
7. After screen reader user
updates value it needs to be
announced
8. Buttons. Needs to convey if
in disabled state
10. Button
11. Heading
12. Is role a radio or a tab? Must
convey selected/checked

21. Identify known accessibility
development patterns
• Headings & levels
• Buttons vs. links
• Data tables
• Disabled elements
• Tabs, Radio buttons, checkboxes
• Collapsed/expanded content
• Live regions (updates w/o screen load)
• All the things WCAG says must be
programatically determined

22. Content
alt text, labels,
instructions
(off-screen & onscreen)
Development
patterns
Known or simple:
tabs, expand/collapse
Complex
development tasks
(do-able)
Not accessible as-is
We need to talk:
interface changes needed
(or an exemption)

23. # Accessibility
1. Calendar will need special
attention from development
team.

24. Complex interactions or elements
• Calendars
• Maps
• Carousel
• Audio/video player
• Custom camera
• Timers

26. Content
alt text, labels,
instructions
(off-screen & onscreen)
Development
patterns
Known or simple:
tabs, expand/collapse
Complex
development tasks
(do-able)
Not accessible as-is
We need to talk:
interface changes needed
(or an exemption)

27. # Accessibility
1. No mechanism for captions
1

29. # Accessibility
1. We need to talk
2. No really. If you can make this
accessible I will buy you all lunch
1 2

30. Not accessible in current state
• No expected data format (if triggers error)
• Missing instructions, required fields
• Media or carousel that cannot be paused
(no controls)
• Video (synchronized) without "CC" option,
unless open captioned
• No transcript link
• Complex interactive charts
• Complex maps
• Complex games

31. Identify issues and options, don't write solutions
Annotation tips What to avoid writing
Needs alt text What the alt text should be
Needs a hidden label What the label should say
Needs consistent heading Should be <h1>
This is a tabset, a button How to code it
Missing X functionality
(e.g. pause/play)
How to code it
Pattern complex, needs
discussion with developers
Write a mini-tutorial in the
wireframe
X element not accessible Use Y instead of X
Assume readers have some
accessibility experience
Teaching Accessibility 101 in
the annotations

32. What you cannot review in a wireframe
A classic wireframe does not include:
• visual design decisions
(such as colours, fonts, positioning, images)
• technical decisions
• Final "copy".
All text is subject to change. Labels and instructions,
headings cannot be reviewed with much certainty.
Checks related to design, code, copy need to
happen later in the project.

33. LET'S REVIEW A WIREFRAME!

35. Content
alt text, labels,
instructions
(off-screen &
onscreen)
Development
patterns
Known or simple:
tabs,
expand/collapse
Complex
development tasks
(do-able)
Not accessible as-is

36. Content
alt text, labels,
instructions
(off-screen &
onscreen)
Development
patterns
Known or simple:
tabs,
expand/collapse
Complex
development tasks
(do-able)
Not accessible as-is

37. Summary of findings for exercise
# Accessibility
1. Needs alt text
2. Needs alt text
3. Needs alt text
4. Heading
5. Heading
6. Heading
7. Needs dynamic alt text depending
on weather. This will need special
attention from development team
8. How the 10 days of icons reads
must be logical. Solution will
need discussion
9. Graph. Will need to discuss
approaches with development

38. Goals of a mockup/wireframe review
Project thinks
about accessibility
early
Catch potential
issues before
development
A head start on
content
Identify
accessibility
development
patterns
Identify complex
accessibility
interactions
Better
requirements
for designers,
developers, QA
No need to be perfect.
Anything you can prevent now is better than later!

39. QUESTIONS & COMMENTS