1. No category

Lessons Learned:
Accessibility Theory vs.
Implementation Reality
CSUN 2014
March 20, 2014
Jennifer Gauvreau, CGI
Hans Hillen, The Paciello Group
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
2
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
3
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
4
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
5
USE CASE 1:
ARIA LANDMARKS
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
6
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-ariapractices/#kbd_layout_landmark_XHTML
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
7
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
3/20/2014
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)
8
ISSUE/SOLUTION DEMONSTRATION:
ARIA MAIN LANDMARK IN IE/JAWS
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
9
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
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
10
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
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
11
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.
3/20/2014
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:
<div id=“content”
role=“main”
title=“”>
…
</div>
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
12
Issue #2: JAWS 13+ Announces
“Region” Before Each Form Field
Issue
Solution
• 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]
3/20/2014
•
•
•
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
CODE SAMPLE:
<div id=“content” role=”main”
title=“”>
<form role=“form”>
…
</form>
</div>
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
13
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
• Example 5 Demonstration
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
14
CONCLUSIONS: ARIA LANDMARKS
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
15
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
16
USE CASE 2:
ARIA DIALOGS
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
17
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
18
Screenshot of Modal Dialog
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
19
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 arialabelledby) 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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
20
ARIA Dialogs: Theory vs. Reality
Accessibility Theory
Implementation Reality
• WAI-ARIA dialog requirements
describe in detail
• Successfully implemented and
tested a custom JQuery UI
Dialog following ARIA
recommendations.
– 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.
3/20/2014
– 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.
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
21
ARIA Dialogs: Specific Issues
Theory
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 arialabelledby 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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
22
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
23
ISSUE/SOLUTION DEMONSTRATION:
ARIA MODAL DIALOGS
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
24
ARIA Modal Dialogs: Demonstrations
• Example 1: Original Modal Dialog
• Example 2: Modified Modal Dialog
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
25
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
26
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
27
CONCLUSIONS:
ARIA MODAL DIALOGS
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
28
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
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.
3/20/2014
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
30
Supporting Windows High Contrast Mode and User-defined Stylesheets
USE CASE 3: ICONS
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
31
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…
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
32
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
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
34
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/textcustomization/r14
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.
3/20/2014
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)
36
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
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
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
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
Windows High Contrast Mode (HCM) and User-defined Style Sheet (USS)
ISSUE/SOLUTION DEMONSTRATION:
ICONS
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
41
Demonstrations
• Icon Solutions
– Example 6: Solution Overview
– Demonstrate Windows High Contrast Mode (HCM)
– Demonstrate User-Defined Style Sheet (USS)
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
42
Sample Page with Original
Styles & Colors
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
43
Sample Page with High Contrast Mode
Enabled
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
44
Sample Page with Original
Styles & Colors (2)
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
45
Sample Page with User-defined Style
Sheet Enabled
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
46
CONCLUSIONS: ICONS
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
47
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
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
SUMMARY
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
50
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
51
Problem/Solution Summary:
Use Cases #2
Use Case
Pain Point
Users Affected
Practical 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 nonvirtual mode in
a dialog
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
52
Problem/Solution Summary:
Use Case #3
Use Case
Pain Point
Users Affected
Practical Solution
#3: Icons
HTML Images are
not a feasible
solution for many
development
teams; CSS
background images
disappear with
HCM; For fontbased 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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
53
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
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=T
ECHNICAL-SUPPORT OR
– Call Technical Support at 727-803-8600
• NVDA: http://community.nvda-project.org/wiki/Issues
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
55
When You’re Back at the Office, Ask Yourself…
NEXT STEPS
3/20/2014
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
56
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
57
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
58
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
Lessons Learned: Accessibility Theory vs.
Implementation Reality (CSUN 2014)
59
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