1 / 60

Lessons Learned: Accessibility Theory vs. Implementation Reality

Lessons Learned: Accessibility Theory vs. Implementation Reality. CSUN 2014 March 20, 2014 Jennifer Gauvreau, CGI Hans Hillen, The Paciello Group. Slides.

maj
Télécharger la présentation

Lessons Learned: Accessibility Theory vs. Implementation Reality

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lessons Learned: Accessibility Theory vs. Implementation Reality CSUN 2014 March 20, 2014 Jennifer Gauvreau, CGI Hans Hillen, The Paciello Group

  2. Slides • Slides are available for download in Microsoft PowerPoint 2010 (PPTX) format using the “Presentation Slides” link at: http://tinyurl.com/csun14lessonslearned Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  3. It Should Work vs. It Does Work • CGI and TPG have been working together for the past 2 years on the accessibility strategy and approach for a variety of web development projects. • Early on the choice was made to use progressive techniques such as WAI-ARIA and HTML 5. • During the implementation it became clear there are discrepancies between how well such solutions work in theory and how well they are supported in practice. Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  4. Roadmap for Today • Discuss 3 specific use cases • For each use case, we will: • outline the theory that drove our approach • describe and demonstrate the issues we encountered • share the workarounds we chose to address inconsistent support by browsers and screen readers. Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  5. Browsers and Screen Readers • Time + Budget = Targeted Testing Profiles • Testing Profile #1: Client’s Standard Configuration • Operating System: Windows 7 • Browsers: Internet Explorer 8 and 9 (IE8 and IE9) • Screen Reader: JAWS (v12 then v13 then v14) • JAWS 15 was not out at the time • Testing Profile #2: “Free” Option • Operating System: Windows 7 • Browser: Firefox (latest version) • Screen Reader: NVDA (latest stable build) Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  6. Use Case 1: ARIA LandmarkS Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  7. ARIA Landmarks • Sighted users can tell at a glance how a page is organized. • Banner • Navigation • Main Content, etc. • Screen reader users benefit when developers define ARIA Landmarks in the HTML layer, which identify structural regions and enhance navigation options. • Refer To: WAI-ARIA Authoring Best Practiceshttp://www.w3.org/TR/wai-aria-practices/#kbd_layout_landmark_XHTML Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  8. ARIA Landmarks: Theory vs. Reality Accessibility Theory Implementation Reality Early in the development lifecycle paired ARIA Landmark roles with new HTML 5 structural elements in new page templates Initially worked as expected at a template level BUT as real content and form functionality was added strange things started to happen… • Easy to implement on existing and new pages • Supported regardless of (X)HTML version • “Win-Win” Support • Older browsers and Assistive Technology (AT) will ignore • Modern browsers and AT provide enhanced semantics and navigation options Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  9. ISSUE/Solution Demonstration: ARIA MAIN LANDMARK in IE/JAWS Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  10. Example 1: No Landmarks CODE SAMPLE: <!-- No Main Landmark Defined --> <div id=“content”> … </div> • Without Landmarks, screen reader user can jump to the main content area by using the “skip navigation” link or by Headings • Example 1 Demonstration Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  11. Example 2: Proper Landmarks CODE SAMPLE: <!-- ARIA Main Landmark Defined --> <div id=“content” role=”main”> … </div> • Same as Example 1 but with standard ARIA Landmarks added • Allows screen reader users to navigate between regions of the page using screen reader quick keys • Semi-colon (;) key in JAWS 10 – 14 • R key in JAWS 15 • D key in NVDA • Example 2 Demonstration Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  12. Issue #1: Form Fields Unusable in JAWS 12 Issue Solution Added null title attribute (title=“”) to fix the problem JAWS 12 announces the proper accessible name/label for the field Example 3 Demonstration • If there were form fields in the main content area and a Main Landmark was defined, the form became very difficult to use. • Before announcing the actual focused field, IE/JAWS 12 would announce the entire contents of the landmark region. CODE SAMPLE: <div id=“content” role=“main” title=“”> … </div> Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  13. Issue #2: JAWS 13+ Announces “Region” Before Each Form Field Issue Solution Wrap the fields in a <div> or <form> and define role="form" on the form container. JAWS stops announcing "region" before announcing the form element BUT new issues SOMETIMES appear… Example 4 Demonstration • Our client upgraded to JAWS 13, and then we saw a new issue appear… • JAWS 13 announces “landmark region” (JAWS 14+ just announces “region”) before the label/accessible name for EACH text entry form field (textbox, select, textarea) • If there is a fieldset/legend then JAWS 13 announces [Legend Text] LANDMARK REGION [Label] CODE SAMPLE: <div id=“content” role=”main” title=“”> <formrole=“form”> … </form> </div> Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  14. Example 3: Pair new HTML 5 <main> element with ARIA role=“main” CODE SAMPLE: <!– HTML 5 w/ARIA Main Landmark Defined --> <mainid=“content” role=”main”> … </main> • Same as Example 2 but non-semantic <div> replaced with new HTML 5 <main> structural element • Example 5 Demonstration Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  15. CONCLUSIONS: ARIA LandmarkS Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  16. ARIA Landmarks: Lessons Learned • IE/JAWS (even JAWS 15) continues to have inconsistent support for ARIA Landmarks • Need to test at a unit (landmark) AND integration (page) level • Use <main role=“main”>…</main> as opposed to the <div role=“main”>…</div> alternative for forms-based web applications • “Do No Harm” • If your site primarily has static content you might not encounter any of these issues • BUT be sure to check any Comment or Feedback forms! Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  17. Use Case 2: ARIA DIALOGS Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  18. ARIA Dialogs • A common web design pattern • Offers an additional “layer” of content to the user while keeping them in the context of their existing task • Visually the dialog is placed on top of the main content of the web page, prompting users for action or guiding them through a separate workflow • ARIA Authoring Best Practices state that the dialog role is a "special case application role“ • All static text must be associated with widgets, groups or panes using the aria-labelledby and aria-describedby properties, otherwise it will not be read by the screen reader when the user navigates to the related widget or group. • Refer To: WAI-ARIA Authoring Best Practices Modal Dialoghttp://www.w3.org/TR/wai-aria-practices/#modal_dialog Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  19. Screenshot of Modal Dialog Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  20. Screen Reader Basics: Navigation Modes Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  21. ARIA Dialogs: Theory vs. Reality Accessibility Theory Implementation Reality Successfully implemented and tested a custom JQuery UI Dialog following ARIA recommendations. Early Design POC used simple placeholder text/form field combinations. BUT problems arose when we began building out pages with real content Dialog designs called for large sections of introductory text, lists, data tables, or other static content. • WAI-ARIA dialog requirements describe in detail • what the markup for a modal dialog should be • how keyboard input and focus should be managed when a dialog is opened or closed. • all static content must be associated with groups, panes, or keyboard focusable widgets through aria-labelledby and aria-describedby relationships. Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  22. ARIA Dialogs: Specific Issues Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  23. ARIA Dialogs: Compromises • Bottom line: The way dialogs are described in the ARIA Spec did not match the reality of how dialogs were used in our project. • Given the architecture, scale and timeline for our project, it was not feasible to expect developers to hand code a unique approach for each modal dialog. • We needed to create a single MODIFIED pattern that would work with the content in our dialogs and be easily reusable by our development teams. Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  24. ISSUE/Solution Demonstration: ARIA MODAL DIALOGs Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  25. ARIA Modal Dialogs: Demonstrations • Example 1: Original Modal Dialog • Example 2: Modified Modal Dialog Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  26. Code Sample Original Dialog: <div tabindex="-1" role="dialog" arialabelledby="ui-id-1"> <div> <h1 id="ui-id-1"tabindex="-1">For Your Information</h1> <a href="#" class="icon-circle_remove" role="button" aria-label="Close“ tabindex="0"> <span class=“HiddenText">Close</span></a> </div> … </div> Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  27. Code Sample Modified Dialog: <div tabindex="-1" role="dialog" arialabelledby="ui-id-1"> <div role="document"aria-label="Dialog contents"> <p class=“HiddenText">Start of dialog</p> <div> <h1 id="ui-id-1"tabindex="-1">For Your Information</h1> <a href="#" class="icon-circle_remove" role="button" aria-label="Close“ tabindex="0"> <span class=“HiddenText">Close</span></a> </div> <div id="dialog" class="contentWrap"> … </div> <p class=“HiddenText">End of dialog</p> </div> </div> Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  28. CONCLUSIONS: ARIA MODAL DIALOGs Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  29. ARIA Modal Dialogs: Lessons Learned • “Adapt” to Design Challenges: • Create proof of concepts early using “real world” content not short strings of boilerplate text • Expand design patterns and authoring best practices to meet new design realities • Support the use of reusable frameworks like JQuery UI to design/build once and then reuse from a centralized solution for ease of maintenance Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  30. For Reference: Modified Dialog Design Pattern • The outer dialog container should • Be marked up with a role="dialog" • Have an aria-labelledby attribute that refers to the id of the heading element for the content of the dialog. • Inside the outer dialog container, wrap ALL the dialog’s content in a "document" role (role=“document”) to allow NVDA screen reader users to navigate the content in virtual mode. • Every dialog must have a title heading marked as an <h1> element • The title heading must be made focusable by adding a tabindex="-1" to it. • When the dialog opens, cursor focus must move to the heading. • When a dialog opens disable all links and form controls outside of the dialog to prevent screen reader users from accidentally activating them • For aria-supported browsers (IE9+, Firefox) use the aria-hidden attribute to remove content that's outside the dialog from the screen reader's virtual buffer • For older browsers (<= IE8) also use a <span> of hidden text at the start and end of the dialog’s content to denote the bounds of the dialog’s content container for screen reader users navigating in virtual mode. • When the dialog closes, return focus to the element that triggered the dialog to open • Support ESCkeypress to close the dialog in addition to any Close/Submit buttons in the dialog Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  31. Supporting Windows High Contrast Mode and User-defined Stylesheets Use Case 3: ICONS Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  32. Icons • Defining alt text to make HTML images accessible is perhaps the first accessibility concept every developer learns. • However, as web designers and developers have embraced new methods for displaying icons we were faced with a new set of accessibility challenges to consider… Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  33. Icons: Requirements • Blind users need equivalent text content for any icons used to convey content, status or meaning • Low vision users need support for user personalization through the use of: • Windows High Contrast Mode themes • User-defined Style Sheets • Disabled Style Sheets • Clients and developers need cost-effective, scalable solutions Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  34. What is Windows High Contrast Mode (HCM)? • A Windows accessibility feature that improves the browsing experience for users with low vision. • Internet Explorer and Firefox inherit the high contrast theme set in Windows: • Background and foreground colors are changed • CSS background images are stripped out. • Has been around for a long time, but is sometimes overlooked in design/development decisions Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  35. What Are User-defined Style Sheets (USS)? • CSS Styles can be overridden by other, “more specific” CSS Styles. • Users can apply their own “user defined stylesheet” to customize web content’s appearance to meet their specific needs. • User defined styles will always trump author defined styles. • User defined style sheets often override background styles and font styles • For more information see Shawn Lawton Henry’s research: http://www.w3.org/WAI/RD/2012/text-customization/r14

  36. Icons: Theory vs. Reality Accessibility Theory Implementation Reality HTML images are not popular slower to load more difficult to maintain than a CSS-based solution like image sprites Developers prefer CSS background images as an efficient way to provide status icons and icon-based widgets/controls. Explored various solutions to find the “best” alternative for our designers and developers… • Web Standards dictates that HTML images should be used for icons conveying information. • CSS background images should NOT be used to convey content and only be used for decorative images or as a redundant visual cue for adjacent text content. Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  37. Issue #1: HTML Images Don’t Inherit High Contrast Theme • HTML images do NOT inherit a user’s high contrast theme (either applied through WHCM or USS) • Images with transparent backgrounds are likely to become unreadable • So, even if CSS background images were replaced with HTML-based images (as is the common recommendation), the images might still be difficult to see for users depending on high contrast color settings. Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  38. Issue #2: No Fallback Text for CSS Background Images • HCM will remove background colors and remove CSS background images but unlike HTML-based images, there is no “alt text” displayed to replace the removed CSS background images. • You can code a hidden span of text off-screen to provide equivalent text content to screen reader users (or users with CSS disabled) but this text is not exposed when using Windows HCM or USS. • This same problem applies with images disabled. Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  39. Solution #1: High Contrast Mode Detection Script • Script detects when background colors or images are overridden or the user disables images in the browser. • Based on this detection, developers can programmatically apply different styles that fix the issues caused by High Contrast Mode, USS, or Images Disabled. Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  40. Solution #2: Use Font-based Icons • CGI Lead UI developer proposed the use of Font-based Icons • Was a great alternative that remained visible and correctly inherited a high contrast theme! • Font-based Icons are a custom font set, loaded through a stylesheet. • Rather than letters, this font set contains text characters that look like icons. • Icons are vector based, can be resized and colored (monochrome) just as regular text can. • Sites such as icomoon.io provide many (free) font icon sets, and allow you create a custom set of your own uploaded icons. • ONE CON: Users with a user-defined stylesheet (USS) may override the font-family, causing the font-based icons to not render properly. • Provide a CSS snippet for users to append to their own custom stylesheet to include the font-family for any font-based icons. • Recent Adobe “Invisible Font” approach seems promising to solve the USS issue

  41. Windows High Contrast Mode (HCM) and User-defined Style Sheet (USS) ISSUE/Solution Demonstration: ICONS Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  42. Demonstrations • Icon Solutions • Example 6: Solution Overview • Demonstrate Windows High Contrast Mode (HCM) • Demonstrate User-Defined Style Sheet (USS) Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  43. Sample Page with Original Styles & Colors Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  44. Sample Page with High Contrast Mode Enabled Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  45. Sample Page with Original Styles & Colors (2) Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  46. Sample Page with User-defined Style Sheet Enabled Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  47. CONCLUSIONS: ICONS Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  48. Icons: Lessons Learned • NO “one size fits all” solution • HTML Images  Define alt text for each image, but ideally need alternative sets of “High Contrast” images (light on dark and dark on light) that could be swapped in once HCM is detected using HCM Detection Script • CSS Background Images  Really should NOT be used to convey content. If they do convey content then you need a text equivalent to fallback to when HC theme is detected using HCM Detection Script • Font-based Icons  Seems to be the overall “winner” when paired with Adobe’s “Invisible Font” approach • BEWARE support in older browsers for font-based icons will require an alternate implementation for IE7 and IE8 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  49. Testing Your Icon Approach • Always test your solution: • In High Contrast Mode (both light on dark and dark on light themes) • With a basic User-Defined Stylesheet (USS) • With Images Disabled • With CSS Disabled Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

  50. Summary Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014)

More Related