Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Early prevention of accessibility issues with mockup & wireframe reviews

2,566 views

Published on

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.

Published in: Technology
  • Be the first to comment

Early prevention of accessibility issues with mockup & wireframe reviews

  1. 1. 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)
  2. 2. 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
  3. 3. ACCESSIBILITY ISSUES ARE PREDICTABLE
  4. 4. Across your accessibility testing, What are the issues you almost always see?
  5. 5. 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
  6. 6. WHAT IS A WIREFRAME OR MOCKUP?
  7. 7. Before the design or the code
  8. 8. 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
  9. 9. A blueprint or schematic
  10. 10. Annotations # Accessibility 1. 2. 2. 3. 4. 5. 6. 7. 8. 9.
  11. 11. 4 types of annotations • 3 relate to predicting & avoiding issues • 1 relates to identifying actual issues that require a change
  12. 12. 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)
  13. 13. 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)
  14. 14. # 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)
  15. 15. 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
  16. 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. 17. # 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
  18. 18. 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
  19. 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. 20. # Accessibility 1. Calendar will need special attention from development team.
  21. 21. Complex interactions or elements • Calendars • Maps • Carousel • Audio/video player • Custom camera • Timers
  22. 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. 23. # Accessibility 1. No mechanism for captions 1
  24. 24. # Accessibility 1. We need to talk 2. No really. If you can make this accessible I will buy you all lunch 1 2
  25. 25. 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
  26. 26. 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
  27. 27. 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.
  28. 28. LET'S REVIEW A WIREFRAME!
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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!
  33. 33. QUESTIONS & COMMENTS

×