Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Lessons Learned: Accessibility Theory vs. Implementation Reality CSUN 2014 March 20, 2014 Jennifer Gauvreau, CGI Hans Hillen, The Paciello Group."— 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: 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 2

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) 33/20/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) 43/20/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) 53/20/2014

6 USE CASE 1: ARIA LANDMARKS Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 63/20/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 Practices practices/#kbd_layout_landmark_XHTMLWAI-ARIA Authoring Best Practices Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 73/20/2014

8 ARIA Landmarks: Theory vs. Reality Accessibility Theory 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 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… Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 83/20/2014

9 ISSUE/SOLUTION DEMONSTRATION: ARIA MAIN LANDMARK IN IE/JAWS 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 9

10 Example 1: No Landmarks CODE SAMPLE: … 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) 103/20/2014

11 Example 2: Proper Landmarks CODE SAMPLE: … 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) 113/20/2014

12 Issue #1: Form Fields Unusable in JAWS 12 Issue 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. Solution Added null title attribute (title=“”) to fix the problem JAWS 12 announces the proper accessible name/label for the field Example 3 Demonstration CODE SAMPLE: … 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 12

13 Issue #2: JAWS 13+ Announces “Region” Before Each Form Field Issue 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] Solution Wrap the fields in a or 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 CODE SAMPLE: … 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 13

14 Example 3: Pair new HTML 5 element with ARIA role=“main” CODE SAMPLE: … Same as Example 2 but non-semantic replaced with new HTML 5 structural element Example 5 Demonstration Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 143/20/2014

15 CONCLUSIONS: ARIA LANDMARKS 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 15

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 … as opposed to the … 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! 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 16

17 USE CASE 2: ARIA DIALOGS Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 173/20/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 Dialog Authoring Best Practices Modal Dialog 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 18

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

20 Screen Reader Basics: Navigation Modes Virtual Mode (a.k.a. browse / virtual PC cursor mode) Non-Virtual Mode ( a.k.a. forms / application mode) Default navigation mode for navigating and reading documents, such as PDF documents or web pages. Default navigation mode for desktop applications, interactive web forms, and web applications (i.e. role=“application”). User navigates through the document with a “virtual cursor”, allowing static content (e.g. plain text, images, data tables) to be traversed as well. Only keyboard accessible content (e.g. focusable elements) or content associated with such elements (e.g. through aria- labelledby) can be accessed.aria- labelledby Screen reader provides special shortcuts and features to enhance virtual navigation, e.g. heading navigation or link lists. Arrow keys are used for basic sequential navigation. No special shortcuts or features are available, except what’s provided by the web page’s level of keyboard accessibility (tabbing, keyboard shortcuts, and scripted movement of keyboard focus). Screen reader will intercept user’s key strokes and break custom keyboard behavior, e.g. a custom widget requiring arrow key input won’t work in this mode. Screen reader lets all keystrokes pass through to the web content. Custom widgets will work as intended provided they are keyboard accessible. 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 20

21 ARIA Dialogs: Theory vs. Reality Accessibility Theory WAI-ARIA dialog requirements describe in detail WAI-ARIA dialog requirements – 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. 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. 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 21

22 ARIA Dialogs: Specific Issues TheoryReality Must move keyboard focus to first focusable element when dialog opens Dialogs often contained too much static content preceding the first form element or link for this to work consistently; setting focus to the first focusable element caused scrolling issues Dialog content must either be keyboard accessible, or associated to content that is (e.g. through an aria- labelledby or aria-describedby relationship) - NVDA users could not toggle between virtual and non-virtual mode preventing them from reading any static content that was outside of the tab order (large blocks of content = cognitive overload) RECENT NEWS: As of 3/13/2014, NVDA includes a new feature resolving this issue ; can now use NVDA+space to switch to browse mode (Enhancement #2023) - JAWS has a character limit when it comes to announcing descriptive text. When the dialog is open, users must be prevented from navigating outside the dialog box with the keyboard or screen reader virtual navigation aria-hidden=“true” not supported in IE8 so alternate solution needed to denote start and end of dialog content from main “parent” page’s content 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 22

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) 233/20/2014

24 ISSUE/SOLUTION DEMONSTRATION: ARIA MODAL DIALOGS 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 24

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

26 Code Sample Original Dialog: For Your Information Close … 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 26

27 Code Sample Modified Dialog: Start of dialog For Your Information Close … End of dialog 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 27

28 CONCLUSIONS: ARIA MODAL DIALOGS 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 28

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 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 29

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 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 ( 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 ESC keypress to close the dialog in addition to any Close/Submit buttons in the dialog 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 30

31 USE CASE 3: ICONS Supporting Windows High Contrast Mode and User-defined Stylesheets Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 313/20/2014

32 Icons 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 32 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…

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 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 33

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) 343/20/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: customization/r14http://www.w3.org/WAI/RD/2012/text- customization/r14

36 Icons: Theory vs. Reality Accessibility Theory 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. 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… Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 363/20/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. 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 37

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. 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 38

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. 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 39

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.icomoon.io 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 ISSUE/SOLUTION DEMONSTRATION: ICONS Windows High Contrast Mode (HCM) and User-defined Style Sheet (USS) 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 41

42 Demonstrations Icon Solutions – Example 6: Solution Overview 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) 423/20/2014

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

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

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

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

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

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 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 48

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 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 49

50 SUMMARY 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 50

51 Problem/Solution Summary: Use Case #1 Use CasePain PointUsers AffectedPractical Solution #1: ARIA Main Landmark Assistive Technology (AT) Bugs Screen Readers1.Use instead of just a to define role=“main” 2.Unit and Integration Test your landmark implementation Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 513/20/2014

52 Problem/Solution Summary: Use Cases #2 Use CasePain PointUsers AffectedPractical Solution #2: ARIA Modal Dialogs WAI-ARIA Spec vs. Design Realities Keyboard, Screen Readers 1.Adapted to create alternate design pattern and reusable proof of concept 2.NVDA recently added a new feature that allows users to toggle between virtual and non- virtual mode in a dialog Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 523/20/2014

53 Problem/Solution Summary: Use Case #3 Use CasePain PointUsers AffectedPractical Solution #3: IconsHTML Images are not a feasible solution for many development teams; CSS background images disappear with HCM; For font- based icons, the font-family can be overridden by USS Windows High Contrast Mode, Images Disabled, User-defined Stylesheets (USS) 1.Use Detection script and/or Font-based Icons 2.Provide sample CSS for USS or use an “invisible font” for hidden text used for icons that convey content Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 533/20/2014

54 Key Themes Do No Harm: – Enhance the UX but don’t prevent users from completing their task Adapt to Design Challenges: – Expand design patterns and authoring best practices to meet new design realities – Create proof of concepts early using “real world” content (e.g., not just small placeholder paragraphs of Lorem Ipsum text) Be Maintainable: – Hacks to workaround browser and AT bugs create extra work for developers – Consider only implementing fixes that can be applied centrally (in CSS or HTML template) to avoid the risk of consistency issues across pages Be Vocal: – File a bug and to help vendors identify defects in the hopes these issues can be fixed centrally and then be available universally 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 54

55 Where to Go to “Be Vocal” in Reporting Browser & AT Bugs Internet Explorer: Firefox: https://bugzilla.mozilla.org/https://bugzilla.mozilla.org/ Chrome: https://code.google.com/p/chromium/issues/listhttps://code.google.com/p/chromium/issues/list Apple: – https://developer.apple.com/bug-reporting/ OR https://developer.apple.com/bug-reporting/ – JAWS: – Technical Support Form at ECHNICAL-SUPPORT OR ECHNICAL-SUPPORT – Call Technical Support at NVDA: Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 553/20/2014

56 NEXT STEPS When You’re Back at the Office, Ask Yourself… Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 563/20/2014

57 Does It Work? Specifications and Best Practices are GOOD BUT just following a Spec doesn’t always work as you’d expect… Be willing to BRAINSTORM, COMPROMISE, and ADAPT in order to develop alternate solutions that really meet the needs of the clients, users and project teams you support. Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 573/20/2014

58 What Makes a Good Solution? USEABLE – Can end users of different abilities EFFECTIVELY use the solution to achieve their goals? FEASIBLE – Given the target architecture and technology, are the accessibility requirements clearly defined so designers and developers can implement a consistent experience? REASONABLE – Define specific accessibility testing profiles based on our clients’ business objectives and budget realities Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 583/20/2014

59 Administrative Wrap-Up Slides Available At: Questions? Contact us at: – Jennifer Gauvreau, CGI – Hans Hillen, The Paciello Group Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 593/20/2014

60 Open Invitation to TPG Bug Bash We really like finding out the cause of strange web accessibility bugs and sharing what we find with browser and AT vendors. – We could use help with tracking down bugs, creating test cases and filing bug reports with browser and AT vendors. – All AT users, QA testers, web developers, vendors, and general accessibility enthusiasts are hereby invited to drop by to help bash some bugs or just hang out! We’ll bring the drinks, snacks and bugs… You grab your favorite device and meet us in the TPG Suite (3233) right after this session, 5:30 pm–6:30 pm. 3/20/2014 Lessons Learned: Accessibility Theory vs. Implementation Reality (CSUN 2014) 60


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

Similar presentations


Ads by Google