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

Lessons Learned: Accessibility Theory vs. Implementation Reality

CSUN 2014March 20, 2014

Jennifer Gauvreau, CGIHans Hillen, The Paciello Group

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

2

Slides

• Slides are available for download in Microsoft PowerPoint 2010 (PPTX) format using the “Presentation Slides” link at: http://tinyurl.com/csun14lessonslearned

3/20/2014

http://tinyurl.com/csun14lessonslearned


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.

3/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.

3/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)

3/20/2014


6

USE CASE 1: ARIA LANDMARKS

3/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 http://www.w3.org/TR/wai-aria-practices/#kbd_layout_landmark_XHTML

3/20/2014

http://www.w3.org/TR/wai-aria-practices/%23kbd_layout_landmark_XHTML

http://www.w3.org/TR/wai-aria-practices/%23kbd_layout_landmark_XHTML


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…

3/20/2014


9

ISSUE/SOLUTION DEMONSTRATION: ARIA MAIN LANDMARK IN IE/JAWS

3/20/2014


10

Example 1: No LandmarksCODE SAMPLE: <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

3/20/2014

https://dl.dropboxusercontent.com/u/573324/CGI/CSUN2014/demos/usecase1_1.html



11

Example 2: Proper LandmarksCODE SAMPLE:

<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


3/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 DemonstrationCODE SAMPLE:

<div id=“content”

role=“main” title=“”> …</div>

3/20/2014





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 <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 DemonstrationCODE SAMPLE:<div id=“content” role=”main” title=“”>

<form role=“form”>…</form></div>

3/20/2014





14

Example 3: Pair new HTML 5 <main> element with ARIA role=“main”

CODE SAMPLE:<!– HTML 5 w/ARIA Main Landmark Defined -->

<main id=“content” role=”main”> …

</main>

• Same as Example 2 but non-semantic <div> replaced with new HTML 5 <main> structural element


3/20/2014



15

CONCLUSIONS: ARIA LANDMARKS

3/20/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!

3/20/2014


17

USE CASE 2: ARIA DIALOGS

3/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 http://www.w3.org/TR/wai-aria-practices/#modal_dialog

3/20/2014

http://www.w3.org/TR/wai-aria-practices/%23modal_dialog


19

Screenshot of Modal Dialog

3/20/2014


20

Screen Reader Basics: Navigation ModesVirtual 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.

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

http://www.w3.org/TR/2011/CR-wai-aria-20110118/states_and_properties%23aria-labelledby


21

ARIA Dialogs: Theory vs. Reality

Accessibility Theory• WAI-ARIA dialog requiremen

ts 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.

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

http://www.w3.org/TR/wai-aria-practices/%23dialog_modal

http://www.w3.org/TR/wai-aria-practices/%23dialog_modal


22

ARIA Dialogs: Specific IssuesTheory Reality

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 2014.1 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


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.

3/20/2014


24

ISSUE/SOLUTION DEMONSTRATION: ARIA MODAL DIALOGS

3/20/2014


25

ARIA Modal Dialogs: Demonstrations

• Example 1: Original Modal Dialog• Example 2: Modified Modal Dialog

3/20/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>

3/20/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>

3/20/2014


28

CONCLUSIONS: ARIA MODAL DIALOGS

3/20/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

3/20/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 ESC keypress to close the dialog in addition to any Close/Submit buttons in the dialog

3/20/2014


31

USE CASE 3: ICONSSupporting Windows High Contrast Mode and User-defined Stylesheets

3/20/2014


32

Icons

3/20/2014

• 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


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

3/20/2014

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

http://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…

3/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


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


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

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

http://icomoon.io/


41

ISSUE/SOLUTION DEMONSTRATION: ICONS

Windows High Contrast Mode (HCM) and User-defined Style Sheet (USS)

3/20/2014


42

Demonstrations

• Icon Solutions– Example 6: Solution Overview– Demonstrate Windows High Contrast Mode (HCM)– Demonstrate User-Defined Style Sheet (USS)

3/20/2014



43

Sample Page with Original Styles & Colors

3/20/2014


44

Sample Page with High Contrast Mode Enabled

3/20/2014


45

Sample Page with Original Styles & Colors (2)

3/20/2014


46

Sample Page with User-defined Style Sheet Enabled

3/20/2014


47

CONCLUSIONS: ICONS

3/20/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

3/20/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

3/20/2014


50

SUMMARY

3/20/2014


51

Problem/Solution Summary: Use Case #1

Use Case Pain Point Users Affected Practical Solution

#1: ARIA Main Landmark

Assistive Technology (AT) Bugs

Screen Readers 1. Use <main> instead of just a <div> to define role=“main”

2. Unit and Integration Test your landmark implementation

3/20/2014


52

Problem/Solution Summary: Use Cases #2


#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

3/20/2014


53

Problem/Solution Summary: Use Case #3


#3: Icons HTML 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

3/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


55

Where to Go to “Be Vocal” in Reporting Browser & AT Bugs

• Internet Explorer: http://connect.microsoft.com/IE • Firefox: https://bugzilla.mozilla.org/ • Chrome: https://code.google.com/p/chromium/issues/list • Apple:

– https://developer.apple.com/bug-reporting/ OR– [email protected]

• JAWS: – Technical Support e-mail Form at http://

www.freedomscientific.com/forms/Contact_FS.asp?ID=TECHNICAL-SUPPORT OR

– Call Technical Support at 727-803-8600• NVDA: http://community.nvda-project.org/wiki/Issues 3/20/2014

http://connect.microsoft.com/IE



https://bugzilla.mozilla.org/

https://code.google.com/p/chromium/issues/list

https://code.google.com/p/chromium/issues/list

https://developer.apple.com/bug-reporting/

mailto:[email protected]

http://www.freedomscientific.com/forms/Contact_FS.asp?ID=TECHNICAL-SUPPORT



http://community.nvda-project.org/wiki/Issues




56

NEXT STEPSWhen You’re Back at the Office, Ask Yourself…

3/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.

3/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

3/20/2014


59

Administrative Wrap-Up

• Slides Available At: http://tinyurl.com/csun14lessonslearned

• Questions? Contact us at:– Jennifer Gauvreau, CGI• Email: [email protected]• Twitter: @jlgauvreau

– Hans Hillen, The Paciello Group• Email: [email protected] • Twitter: @hanshillen

3/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 March 20, 2014 Jennifer Gauvreau, CGI Hans Hillen, The Paciello Group.

Documents