Accessibility Overview - 508 and WCAG Compliance

Accessibility Overview
----Please Review Slide Notes---
Frank Walsh
fwalsh@amplify.com
Solutions Architect
Consulting Group

• About Me
• Major Categories of Disabilities
• Statistics
• Laws and Standards
• WCAG 2.0
• Principles of Accessible Design
• Accessible Design
• Closed Captioning
• Well Formed & Accessible HTML
Overview
• Rich Internet Applications
• How is Web Accessibility Evaluated
• Testing and Validation Tools
• Screen Reader Statistics
• Alternative Approaches
• Last Resort Approach
• Authoring Tool Accessibility
• APIP & QTI

● Visual
○ Blindness
○ Color-blindness
○ Low vision - refers to individuals who have enough sight to use a visual browser, but who
may need to enlarge text or use special high-contrast font and color settings in order to
access online information.
● Hearing
○ Deafness and hard-of-hearing
● Motor/Ambulatory/Self-care
○ Slow response time, limited fine motor control, difficulty walking or climbing stairs, bathing
or dressing
● Learning/Cognitive
○ Learning disabilities, distractibility, inability to remember or focus on large amounts of
information
Major Categories of Disabilities We’ll Cover
For more Detail Read the Individuals with Disabilities Education Act (IDEA)

Americans With Disabilities: 2010
Of the 62.2 million children under the age of 15, about 5.2 million or 8.4 percent had some kind of
disability. Half of which were classified with severe disabilities.
Among children aged 6 to 14, 4.5 million children (12.2 percent) in this age group had a disability.
Roughly 5.3 percent had a severe disability and 0.8 percent needed assistance with one or more
assisted learning device.
American Printing House for the Blind, 2014 Annual Report
Total number of students through age 21 with Vision Loss: 60,393
By reporting agency
● Reported by state departments of education: 50,205 (83.1%)
● Reported by residential schools for the blind: 5,133 (8.5%)
● Reported by rehabilitation programs: 3,661 (6.1%)
● Reported by multiple disability programs: 1,394 (2.3%)
Statistics

Disability Statistics, American Community Survey (2012)
The number of non-institutionalized males or females, ages 4 and under through 20, all races,
regardless of ethnicity, with all education levels in the United States who reported a visual disability in
2012.
Total: 659,700
Blindness among adults (2012)
The number of non-institutionalized, male or female, ages 16 through 75+, all races, regardless of
ethnicity, with all education levels in the United States reported to have a visual disability in 2012.
Total (all ages): 6,670,300
Total (16 to 75+): 6,211,700
Age 18 to 64: 3,412,900
Age 65 and older: 2,724,600
Statistics

Basic Facts About Hearing Loss
About 20 percent of adults in the United States, 48 million, report some degree of hearing loss.
● 60 percent of the people with hearing loss are either in the workforce or in educational settings.
● About 2-3 of every 1,000 children are hard of hearing or deaf
● Estimated that 30 school children per 1,000 have a hearing loss.
Statistics

● Section 504 of the Rehabilitation Act of 1973
○ Accessible format in a timely manner
● The Americans with Disabilities Act (ADA) of 1990
● Section 508 (2000) Information Technology Accessibility Standards
○ 14 requirements (based on Priority 1 requirements of WCAG 1.0)
● W3C Web Content Accessibility Guidelines 1.0 (1999)
○ 14 Guidelines
○ 65 Checkpoints (16 P1, 30 P2, 19 P3)
● W3C Web Content Accessibility Guidelines 2.0
○ 4 Principles
○ 12 Guidelines
○ 61 Success Criteria (26 level A, 13 level AA, 22 level AAA)
Section 508 defines accessibility as access to and use of information and data that is comparable to the access
to and use of the information and data by those who are not individuals with disabilities.
Although Section 508 addresses the accessibility of information technology by people with disabilities, it is no
guarantee of practical usability by them. While usability is not mandated by federal regulations, it has become a
best practice in government and industry.
Laws and Standards

● Principles - Four principles that provide the foundation for Web accessibility: perceivable, operable,
understandable, and robust.
● Guidelines - Under the principles are guidelines. The 12 guidelines provide the basic goals that
authors should work toward in order to make content more accessible to users with different
disabilities. The guidelines are not testable, but provide the framework and overall objectives to help
authors understand the success criteria and better implement the techniques.
● Success Criteria - For each guideline, testable success criteria are provided to allow WCAG 2.0 to be
used where requirements and conformance testing are necessary such as in design specification,
purchasing, regulation, and contractual agreements. In order to meet the needs of different groups and
different situations, three levels of conformance are defined: A (lowest), AA, and AAA (highest).
● Sufficient and Advisory Techniques - For each of the guidelines and success criteria in the WCAG
2.0 document itself, the working group has also documented a wide variety of techniques. The
techniques are informative and fall into two categories: those that are sufficient for meeting the success
criteria and those that are advisory. The advisory techniques go beyond what is required by the
individual success criteria and allow authors to better address the guidelines.
● In order to meet the needs of different groups and different situations, three levels of conformance
are defined: A (lowest), AA, and AAA (highest).
WCAG 2.0 Layers of Guidance

Perceivable - Available to the senses (vision and hearing primarily) either through the browser or
assistive technologies (e.g. screen readers, screen enlargers, etc.)
Operable: Users can interact with all controls and interactive elements using either the mouse,
keyboard, or an assistive device
Understandable: Content is clear and limits confusion and ambiguity
Robust: A wide range of technologies (including old and new user agents and assistive technologies)
can access the content
Four Principles of WCAG - POUR

Guideline 1.2 Time-based Media: Provide alternatives for time-based media.
1.2.1 Audio-only and Video-only (Prerecorded): For prerecorded audio-only and prerecorded video-only media, the
following are true, except when the audio or video is a media alternative for text and is clearly labeled as such: (Level A)
Prerecorded Audio-only: An alternative for time-based media is provided that presents equivalent information for
prerecorded audio-only content.
Prerecorded Video-only: Either an alternative for time-based media or an audio track is provided that presents
equivalent information for prerecorded video-only content.
1.2.2 Captions (Prerecorded): Captions are provided for all prerecorded audio content in synchronized media, except
when the media is a media alternative for text and is clearly labeled as such. (Level A)
1.2.3 Audio Description or Media Alternative (Prerecorded): An alternative for time-based media or audio description
of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text
and is clearly labeled as such. (Level A)
All Guidelines include a “How To Meet” (i.e. Success Criteria and Techniques) and “Understanding…” (i.e. Examples
and Benefits) supplemental documentation.
WCAG Guideline - Example

Applying accessibility techniques to an unusable site is like putting lipstick on a
pig. No matter how much you apply, it will always be a pig.
No amount of technical accessibility can fix something that is not useful or
usable. Often the approach to poor usability is to throw more accessibility code at a
site. Technical guidelines and solutions are used to attempt fixes for non-technical
problems. The POUR principles are applied before considering usefulness and
usability. And worse, poor usability is sometimes justified by declaring, “But it’s
compliant!”
Accessibility Lipstick on a Usability Pig
Types of accessibility lipstick commonly applied to usability pigs:
● Off-screen explanations or ARIA labels so a screen reader user might make sense of an overly complex form.
● Tabindex and keyboard interaction detection on <div> or <span> elements instead of using standard buttons or links.
● Custom widgets when native controls provide the same or sufficient functionality.
● Headers and id to markup a data table that is so complex a screen reader user is unlikely to ever comprehend it.
● Text-only or screen reader versions.
● In-page text resizing widget because a page does not support user-increased text sizes.
Many accessibility techniques can be avoided by considering usability first. Does the site make sense? Is it easy to use? Is it
presented in a logical manner? Are the interactions standard and intuitive? Is the content useful and clearly written? Does the
design enhance or detract from the core content and functionality? The answers to these questions affect both usability and
accessibility for everyone, regardless of disability. When designed or restructured for optimal usability for everyone, accessibility
then becomes much easier, and is often found to have been addressed entirely in the usability fixes.

● Provides Alternate Text (e.g. Embedded images)
● Provides Appropriate Document Structure
● Provides Headers for data tables
● Ensure users can complete and submit all forms
● Ensure links make sense out of context (e.g. Return to Home instead of CLICK HERE )
● Captions and/or provide transcripts for media (e.g. Video & Embedded Audio)
● Ensure accessibility of non-HTML content (e.g. PDFs, Word Documents, PowerPoint, Flash)
● Allow users to skip repetitive elements on a page (e.g. Skip Menu Navigation)
● Do not rely on color alone to convey meaning
● Make sure content is clearly written and easy to read
● Make Javascript accessible (e.g onmouseover should have onfocus)
Principles of Accessible Design & Development - Usability

● Cover your eyes and use assistive technology (e.g. JAWS screen reader), are you not only being
presented the same information BUT ALSO having a similar experience. (What if you were
colorblind?)
● Cover your ears, are you not only seeing the same information BUT ALSO being prompted by the
system in the same way.
● Navigate without your mouse, are you able to smoothly progress through the system and
accomplish the same goals.

Accessible
Design
Click the Green Circle….

Font Selection, Font Size & Font Movement

“Ems” (em): The “em” is a scalable unit that is used in web document media. An em is equal to the
current font-size, for instance, if the font-size of the document is 12pt, 1em is equal to 12pt.
Percent (%): The percent unit is much like the “em” unit, save for a few fundamental differences. First
and foremost, the current font-size is equal to 100% (i.e. 12pt = 100%). While using the percent unit,
your text remains fully scalable for mobile devices and for accessibility.
VS
Pixels (px): Pixels are fixed-size units that are used in screen media (i.e. to be read on the computer
screen). One pixel is equal to one dot on the computer screen (the smallest division of your screen’s
resolution). Many web designers use pixel units in web documents in order to produce a pixel-perfect
representation of their site as it is rendered in the browser. One problem with the pixel unit is that it
does not scale upward for visually-impaired readers or downward to fit mobile devices.
Points (pt): Points are traditionally used in print media (anything that is to be printed on paper, etc.).
One point is equal to 1/72 of an inch. Points are much like pixels, in that they are fixed-size units and
cannot scale in size.
Font Size - Relative Units vs Absolute Units

Normal browser font size is typically 12pt.
Large text is 1.2em BOLD (i.e. 14pt).
Large text is 1.4em NOT BOLD (i.e. 18pt).
Font Size - Relative Units vs Absolute Units
SC 1.4.4 Resize Text:Except for
captions and images of text, text
can be resized without assistive
technology up to 200 percent
without loss of content or
functionality. (Level AA)

These users often employ the following assistive technologies, or use the following technologies in an assistive manner:
● special software, including keyboard emulators, sticky keys and predictive text systems
● voice recognition software
● mouth wands, or other means of using head movements to register commands
● touch and tap pads and switches
● eye tracking software
The following accessibility features, or ways of coding, assist the above technologies:
● ability to arrow or tab through pages and all components of a page that a user might click on with a mouse
● less content on each page
● no timed responses, ability to pause and replay content
● no activities which focus on very exact positioning or repositioning of objects on the screen.
● “back to top” links
● drop down menus navigate-able with keyboard
● multiple forms of navigation
● Buttons that are not unreasonably small
Accessibility for Individuals with a Motor Disability

● SubRip WebSRT (.srt) renamed WebVTT (WHATWG)
○ Desktop (Chrome 23+, Firefox 31+, Internet Explore 10.0, Opera
12.10, Safari 6)
○ Mobile (Chrome 4.4, Opera 21, Safari 7)
● Timed Text Markup Language (W3C)
Closed Captioning
WEBVTT TTML
WebVTT: IE 10+, Chrome, Safari,Opera, Firefox (Limited) - Is Quickly Becoming The Web Standard
Note: NOT IE 8.0 Compatible

Browser Statistics
Legacy Versions of Internet
Explorer still have major role in K-
12 School Browser Usage.

Browser Usage among Users with a Viewing Disability

Primary Screen Reader among Users with a Viewing Disability

What is a Polyfill?
A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you,
the developer, expect the browser to provide natively.
Closed Captioning - Javascript Polyfill

For SBAC 23 we used some open source code called JS_VideoSub since we already had player
controls embedded in the UI, were only supporting newer IE versions and simply wanted to add
captioning. Due to the MIME type for .srt being unsupported by our web server, we renamed the
caption file to the extension .html
Other options provide full video playback controls and captioning functionality:
Using a Polyfill..

Voxcribe & Camtasia - Speed Recognition Captioning
Voxcribe is great, but Camtasia proved to be
faster and even cleaner, you simply import
video...run speech-to text then EXPORT the
caption SRT. You can then trash the Camtasia
project.

Choosing Text Equivalents for Images And Image Links
<img src="images/shop.gif" alt="Shop IBM" />
It might be tempting to write alternative text like this:
alt="abstract shopping cart to the left of the words shop IBM"
That is the description of the image, not its function. If you used that alt-text then each time a blind person
visited the site he or she would have to listen to "abstract shopping cart to the left of the words shop IBM." That
image and that message would be at the top of every page. Such a description meets the technical
standard (§1194.22 (a)) for providing a text equivalent, but it fails usability criteria. Instead, use
alternative text, as IBM does, that exactly coincides with the text on the image or the function of the link,
alt="Shop IBM".

Semantic HTML is the use of HTML markup to reinforce the semantics, or meaning, of the information in web pages
rather than merely to define its presentation or look.
Example: Recent HTML standards discourage the use of the <i> italic tag in preference for the more accurate <em>
emphasis tag, where a CSS stylesheet would denote the italization of the font. The fact of the matter is, semantics
largely benefit everyone. For starters, semantics provide a shared and unambiguous meaning to content.
Do not use text formatting, such as font size or bold to give the visual appearance of headings - use actual
heading (<h1> - <h6>) for all content headings. Assistive technologies and other browsers rely upon the literal
markup of the page to determine structure. Items that are bolded or display in a bigger font are not interpreted to be
structural elements. HTML lists - <ul>, <ol>, and <dl> - also convey a hierarchical content structure.
Structural Semantics - <h1>,<h6>,<p>,<li>
HTML Semantics - <header>,<main>,<article>,<aside>,<footer>
Text-level Semantics - <strong>,<em>,<small>,<code>
WAI-ARIA - <alert>,<checkbox>,<slider>,<tab>,<tabpanel>,<treeitem>
Accessibility - Web Development - Semantic HTML

The Document Object Model (DOM) is a cross-platform and
language-independent convention for representing and
interacting with objects in HTML, XHTML and XML
documents.[1] The nodes of every document are organized in a
tree structure, called the DOM tree.
AJAX - Asynchronous Javascript + XML is a group of
interrelated Web development techniques used on the client-
side to create asynchronous Web applications. (i.e. Web
Applications that change the user experience while
retrieving/sending data to a server in the background).
The DOM is accessed with JavaScript to dynamically display –
and allow the user to interact with – the information presented.
Document Object Model (DOM) and Rich Internet Applications

Document Object Model (DOM) and Rich Internet Applications
In many cases, this is a lot like trying to
pin a tail on a moving donkey or playing
Marco Polo.
Screen Readers read the semantic
structure of the HTML as it was constructed
in the DOM tree at the time a page is
rendered, and then present that information
to the user.
This places the burden of
comparing/contrasting the changing DOM
tree on the screen reader. Raising
questions like:
● At what frequency?
● What is an important update to read,
what isn’t?
● How should the update be read, in the
context of some information that didn’t
change or alone?

WAI-ARIA, the Accessible Rich Internet Applications
Suite, provides a way to make Web content and Web
applications more accessible to people with disabilities.
It especially helps with dynamic content and advanced
user interface controls developed with Ajax, HTML,
JavaScript, and related technologies.
Example: The aria-live="assertive" attribute means
that the value of the text field will be spoken whenever it
changes.
Enter WAI - ARIA...

● User Groups
● Automated Validation Tools
● QA with Screen Reader and Accessibility / Legacy Configured Browsers
● WCAG-EM - Website Accessibility Conformance Evaluation Methodology
Outcomes:
● Statement of Accessibility
● 508 Voluntary Product Accessibility Template (VPAT)
● WCAG 2.0 Conformance Claim
How is web accessibility evaluated?

● W3C Markup Validation Service - http://validator.w3.org/
● Web Accessibility Evaluation Tool - http://wave.webaim.org/
● SortSite - http://www.powermapper.com/products/sortsite/
● JAWS - http://www.freedomscientific.com/Products/Blindness/Jaws
● NVDA - http://www.nvaccess.org/
● WebAIM Contract Checker - http://webaim.org/resources/contrastchecker/
● AccessColor - http://www.accesskeys.org/tools/color-contrast.html
● Fangs Screen Reader Emulator for Firefox - https://addons.mozilla.org/en-
US/firefox/addon/fangs-screen-reader-emulator/
● Chrome Resize Window Plugin and Sizer Windows TSR
● Illinois Functional Accessibility Evaluator - http://fae20.cita.illinois.edu/
● Apple VoiceOver
Testing and Validation Tools

● W3C Markup Validation Service - http://validator.w3.org/
● Web Accessibility Evaluation Tool - http://wave.webaim.org/
● SortSite - http://www.powermapper.com/products/sortsite/
● JAWS - http://www.freedomscientific.com/Products/Blindness/Jaws
● NVDA - http://www.nvaccess.org/
● WebAIM Contract Checker - http://webaim.org/resources/contrastchecker/
● AccessColor - http://www.accesskeys.org/tools/color-contrast.html
● Fangs Screen Reader Emulator for Firefox - https://addons.mozilla.org/en-US/firefox/addon/fangs-
screen-reader-emulator/
● Chrome Resize Window Plugin and Sizer Windows TSR
● Illinois Functional Accessibility Evaluator - http://fae20.cita.illinois.edu/
● Apple VoiceOver - https://www.apple.com/accessibility/ios/
● Wave Toolbar - https://addons.mozilla.org/en-US/firefox/addon/wave-toolbar/
● Juicy Studio - https://addons.mozilla.org/en-US/firefox/addon/juicy-studio-accessibility-too/?src=search
● Accessibility Evaluation Toolbar - https://addons.mozilla.org/en-US/firefox/addon/accessibility-
evaluation-toolb/?src=search
● Headings Map - https://addons.mozilla.org/en-US/firefox/addon/headingsmap/
Testing and Validation Tools

Great testing tools…Lynx Text Based Browser

Great testing tools… SortSite

Alternative Approaches
What is equivalent facilitation?
Equivalent facilitation is not an exception or variance from the requirement to provide
comparable access. Rather, it is a recognition that technologies may be either developed
or used in ways not envisioned by the technical provisions in WCAG 2.0 but still result in
the same or better functional access as would be provided by strictly meeting the
provisions of WCAG 2.0. Functional outcome – not form – is the key to evaluating
whether a technology results in "substantially equivalent or greater access."
For example, an information kiosk which is not accessible to a person who is blind might
be made accessible by incorporating a telephone handset connected to a computer that
responds to touch tone commands and delivers the same information audibly that is
provided on the screen.
What is the difference between "equivalent facilitation" and "alternative means of access"?
Alternative means of access focuses on the accessing of equivalent content where as equivalent
facilitation focuses more so on the experience/sequence/reveal by which that content is delivered.

Alternative Approaches for Absolutely Positioned Elements

Text-Only Page as a Last Resort
This last special case was included in the Section 508 Standards as a "last resort method for bringing a
Web site into compliance with the other requirements in §1194.22."
§ 1194.22 (k)
A text-only page, with equivalent information or functionality, shall be provided to make a Web site
comply with the provisions of this part, when compliance cannot be accomplished in any other
way. The content of the text-only page shall be updated whenever the primary page changes.
If you must resort to providing a text-only alternative page, you must ensure the following:
1. Provide a clear link to the alternative page.
2. Ensure that the alternative page is accessible.
3. Ensure that the alternative page has equivalent information or functionality.
4. Update the alternative page as often as you update the original page.

The Authoring Tool Accessibility Guidelines (ATAG) documents explain how to make the authoring
tools themselves accessible, so that people with disabilities can create web content, and help authors
create more accessible web content — specifically: enable, support, and promote the production of
content that conforms to Web Content Accessibility Guidelines (WCAG).
LOOK FOR A VPAT!
ATAG - Authoring Tools Accessibility Guidelines &
User Agent Accessibility Guidelines
DON’T BELIEVE THE HYPE!

What is QTI?
QTI is the most widely used standard for marking up assessments, tests, and individual questions
in XML short for Question and Test Interoperability (QTI). IMS is an e-learning standards-related
organization that works on standards ranging from metadata to transferring learner information.
QTI standardizes how to mark up questions in XML, arrange them into tests and assessments,
add metadata, and package everything in a ZIP file.
QTI XML not only describes the static parts of questions, assessments, and tests (text,
layout,order, and so on) but also their dynamic behavior—how, for instance, to behave when the
user gives a wrong answer, when to provide certain feedback, and how to calculate the score.
You can make this process as complicated as you like: QTI provides you with programming
facilities to make it all happen.
What is APIP?
Built on existing standards that service providers can readily adopt, the APIP standard provides
the technical framework required to modify or develop item authoring, item banking and test
delivery systems so they can create and deliver items and tests that are—for the first time in our
field —portable and highly accessible. APIP cover three critical areas:
● Content: The accessible content, which has supporting information for
different kinds of accessibility needs
● PNP: The user Personal Needs and Preferences profile, which tells the
delivery system what the needs are for specific users
● Delivery: The delivery system, which combines the user needs with the
content to ensure the item is accessible for the student
APIP and QTI

Anatomy of a QTI Item
APIP and QTI
A <responseDeclaration> contains information about the answer (the response) to a question: When is it correct, and (optionally) how is it scored? A
<responseDeclaration> is required for every separate question in the <itemBody>.
An <outcomeDeclaration> defines an internal variable—for instance, for returning the score to the environment or for controlling the feedback to the user.
The single <itemBody> element contains the text, markup, and questions for this item. Themarkup has a remarkable similarity with XHTML, but beware: Although you see
familiarelements like <p> and <ul>, everything is in the QTI namespace (http://www.imsglobal.org/xsd/imsqti_v2p1) and not in the XHTML namespace. The standard does
not prescribe that you have to render it with a browser, which leaves a lot of room for interpretation. So,consistent rendering is a major problem when exchanging content
between different QTI processing engines
The <responseProcessing> section describes the actions to perform when the student is finished with the item. Its content is a simple programming language in which you
can perform computations, set <outcomeDeclaration> variables, and more.
Finally, <modalFeedback> defines the item's feedback to the student (for instance, display "Welldone" when the answer is correct).

What standards is APIP based on?
APIP is based on three existing interoperability standards:
● QTI: The IMS Question & Test Interoperability Specification provides standard XML language for describing questions and tests. The specification has been produced to
allow the interoperability of content within assessment systems. QTI is well-established and has been used internationally for over a decade. APIP uses the newer 2.1
version of QTI.
● Access for All: The Access for All Personal Needs and Preferences (PNP) standard defines a common way for describing a student’s needs and preferences in a digital
environment. PNP allows an inclusive user experience by enabling the matching of the characteristics of learning resources to the needs and preferences of individual
students.
● Content Packaging: IMS Content Packaging (CP) is used to collate all of the QTI and accessibility information and to structure it in a convenient exchange format (once
collated, the package is exchanged as a zip file).
APIP and QTI

Accessibility Overview - 508 and WCAG Compliance

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Accessibility Overview - 508 and WCAG Compliance (20)

Accessibility Overview - 508 and WCAG Compliance