Early prevention of accessibility issues with mockup & wireframe reviews
-
Upload
aidan-tierney -
Category
Technology
-
view
1.077 -
download
0
Transcript of Early prevention of accessibility issues with mockup & wireframe reviews
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)
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
ACCESSIBILITY ISSUES ARE
PREDICTABLE
Across your accessibility testing, What
are the issues you almost always see?
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
WHAT IS A WIREFRAME OR MOCKUP?
Before the design or the code
A website wireframe, also known as a page schematic or 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 software applications. en.wikipedia.org/wiki/Website_wireframe
A blueprint or schematic
Annotations
# Accessibility
1.
2.
2.
3.
4.
5.
6.
7.
8.
9.
4 types of annotations
• 3 relate to predicting & avoiding issues
• 1 relates to identifying actual issues that
require a change
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)
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)
# 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)
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
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)
# 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
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
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)
# Accessibility
1. Calendar will need special
attention from development
team.
Complex interactions or elements
• Calendars
• Maps
• Carousel
• Audio/video player
• Custom camera
• Timers
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)
# Accessibility
1. No mechanism for captions
1
# Accessibility
1. We need to talk
2. No really. If you can make this
accessible I will buy you all lunch
1 2
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
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
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.
LET'S REVIEW A WIREFRAME!
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
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
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
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!
QUESTIONS & COMMENTS