Do you see what i see?

transcript

How To Design Websites For Blind and Visually Impaired Users

• Have been working with IBM/Lotus Notes, Domino & XPages since R2.0

• Presented at three previous MWLUGs (Milwaukee, Cleveland and Pittsburgh)

• Co-author of Special Edition: Using Lotus Notes & Domino 4.5 and 4.6

• LotusSphere Booth-babe for Ytria, NotesCode, and Mobilite

• Previous clients include: Canal Barge Company, PNC Bank, Teledyne, Sierra Nevada Corp., Morey Corp, Uline, Abbott Labs, Tenneco, YMCA and many more

ROY RUMANER

• Randy Horwitz is currently a manager on the Bluemix development team in Austin, TX where his team develops a mobile analytics solution as part of that platform.

• He is known across IBM as an accessibility subject matter expert. Not only does he know the technology, he has to live it daily as he is totally blind.

• In the past, he has also served as the manager of the Austin Extreme Blue lab, where he prepared teams of interns to present to top IBM executives at IBM’s headquarters.

RANDY HORWITZ

The Who?The Why?

The How?The Demo

The Questions

Agenda

Currently, most studies find that about one fifth (20%) of the population has some kind of disability. Not all of these people have disabilities that make it difficult for them to access the internet, but it is still a significant portion of the population.

The major categories of disability types are:• Visual – Blindness, low vision, color blindness (6.4M)• Hearing – Deafness and hard of hearing (10.5M)• Motor – Inability to use a mouse, slow response time, limited fine

motor control (20.9M)• Cognitive – Learning disabilities, distractibility, inability to remember or

focus on large amounts of information (14.8M)

The Who: People with Disabilities on the Web

When something needs to be accessible on the Web, it means that user can interact with it using any assistive technology (AT) they may use, such as:

– screen reading software which reads the page to the user– magnification software that enlarges the screen– speech recognition software that allows users to control your

page with voice commands– alternative input devices that mimic a standard keyboard– refreshable braille displays which transform the content into

braille

The Who: What is accessibility?

To design something so that it is accessible means can all people, regardless of any impairment, interact with your content.

For instance:• How does someone who cannot use a mouse interact with your Web

page? • What if they cannot see? • Does your site accommodate older populations and the issues they

The Who: What is required to design accessibly?

To help answer those questions there are laws and standards which define:

– whose sites have to be accessible– what type of content has to be accessible– who needs to be able to access it– how you determine what is and what is not

accessible

The Who: What is required to design accessibly?

In order to make all of this work, careful planning must be made when designing electronic content. While assistive technologies (AT) have made significant advances, they cannot perform magic.

The Who: The six P’s

Before anyone can make their web site accessible, they must understand accessibility, be committed to ensuring accessibility, learn how to implement accessibility, and understand their legal obligations.

The Who: Implementing Web Accessibility

Awareness– The foundation of any kind of commitment to web

accessibility is awareness of the issues. Most web developers are not opposed to the concept of making the internet accessible to people with disabilities. Most accessibility errors on web sites are the result of lack of awareness, rather than malice or apathy.

The Who: Commitment and accountability

Leadership– Understanding the issues is an important first step,

but it does not solve the problem, especially in large organizations.

• If the leadership of an organization does not express commitment to web accessibility, chances are low that the organization's web content will be accessible.

• Oftentimes, a handful of developers make their own content accessible while the majority don't bother to, since it is not expected of them.

Policies and Procedures– Even when leaders express their commitment to an

idea, if the idea is not backed up by policy, the idea tends to get lost among the day-to-day routines.

• The best approach for a large organization is to create an internal policy that outlines specific standards, procedures, and methods for monitoring compliance.

Training and technical support– Sometimes web developers fear that it is more

expensive and time-consuming to create accessible web sites than it is to create inaccessible ones.

• This fear is largely untrue. The benefits of providing access to a larger population almost always outweigh the time required by a knowledgeable developer to implement that accessibility.

Think of this as both GOOD ETHICS(it is the right thing to do)

GOOD BUSINESS(it is the law, or soon will be)

The Who: Why should I care?

Some of the applicable laws regarding Web accessibility are:

– Americans with Disabilities Act (ADA)– Section 508 of the Rehabilitation Act (Section 508)– Individuals with Disabilities Education Act (IDEA)– and more at http://webaim.org/articles/laws/usa/– Section 255 of the Telecommunications Act– Web Content Accessibility Guideline 2.0 (WCAG 2.0)

The Who: Accessibility Basics and the Law

The Americans with Disabilities Act of 1990 guarantees certain rights to people with disabilities in four main areas and permits people with disabilities to file civil lawsuits to obtain “reasonable accommodation”.

– ADA Title I: Employment (private, local, and state)– ADA Title II: Public entities, including state and local

government and their departments and agencies– ADA Title III: Places of public accommodations and private

entities– ADA Title IV: Telecommunications providers

The Who: Americans with Disabilities Act

Section 508 is part of a larger piece of legislation called The Rehabilitation Act of 1973.

– The Rehabilitation Act prohibits discrimination on the basis of disability in Federal programs, among other things.

It's a law that requires Federal agencies to procure and develop technologies that meet a specific accessibility standard. It is also a standard in that it covers all aspects of IT from Web pages to desktop software applications to telecommunications equipment

The Who: What is Section 508?

Web Content Accessibility

Guidelines 2.0

– The Web Content Accessibility Guidelines are a set of technical standards.

– The WCAG has 4 principles (POUR) that are broken down into 12 guidelines

– Those 12 guidelines are further broken down into success criteria

– For each success criteria there are 3 levels of conformance• A, AA*, AAA

The Who: What is the WCAG 2.0?

POUR – Four Principles of Accessibility– Content must be Perceivable– Interface components in the content must be

Operable – Content and controls must be Understandable – Content should be Robust enough to work with

current and future user agents (including assistive technologies)

The Who: WCAG Principles - POUR

• Provide text alternatives for any non-text content

• Provide alternatives for time based media• Separate content from style• Make it easier for users to see and hear

content

The Who: WCAG Guidelines - Perceivable

• Make all functionality available from a keyboard

• Provide users enough time to read and use content

• Do not design content known to cause seizures

• Provide ways to help users navigate, find content and determine where they are

The Who: WCAG Guidelines - Operable

• Simplify text content• Web pages operate in predictable ways• Help users avoid and correct mistakes

The Who: WCAG Guidelines - Understandable

• Maximize compatibility with other products, including assistive technologies

The Who: WCAG Guidelines - Robust

The Who: WCAG Guidelines – Success Levels

Level A We must satisfy these requirements, otherwise it will be impossible for one or more groups to access the web content

Level AA We should satisfy these requirements, otherwise some groups will find it difficult to access the web content

Level AAA We may satisfy these requirements, in order to make it easier for some groups to access the web content

Of the 38 Level A and AA provisions,

about 50% impact website design

The Who: The Four Principles of Accessibility

Examples of the Visual / Audio Design

Provisions

Guideline 1.4.1 Level A Color – Color should not be the only visual means of conveying essential

information. Recommended strategies include providing text cues or using patterns in addition to different colors.

The Who: WCAG Guidelines – Visual / Audio Design

Guideline 1.4.3 Level AA Contrast – Text should have a contrast ratio of at least 4.5 to 1 to accommodate

users with mild visual impairments. • Large Text: Large-scale text, logos and images of large-scale text have a

contrast ratio of at least 3:1;• Incidental: Text or images of text that are part of an inactive user

interface component (UI), that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

• Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

Guideline 1.4.4 Level AA Text Size – Text should be resizable up to 200% for users with mild visual

impairments.• Many modern browsers provide a zoom function for the entire page to

accommodate this.

Guideline 2.3.1 Level A Seizures – Content should not be designed in a way known to cause seizures in

users with photosensitive epilepsy. Elements occupying a significant portion of the display that flash more than three times in one second should be tested for compliance.

• The Trace Center Photosensitive Epilepsy Analysis Tool (PEAT) is available at trace.wisc.edu/peat/

Guideline 2.4.7 Level AA Focus – Users with motor impairments who rely on the keyboard to navigate

need a clear visual focus indicator.• Many modern browser’s include built-in support to accommodate this.

Guideline 3.3.2 Level A Forms – Labels or instructions should be included whenever user input is

required, and should be positioned near the elements they reference.

Guideline 3.3.2 Level A Instructions – Instructions should not depend solely on a user’s ability to see the

content as presented. For example, “Press the button on the right” requires visual information, while “Press the ‘submit’ button on the right” does not.

Guideline 1.4.2 Level A Audio – Audio that plays automatically may interfere with screen readers.

Any audio that plays automatically must be less than three seconds, or provide an easily accessible mechanism to stop it.

Examples of the Interaction Design

Provisions

Guideline 2.1.1 Level A Keyboard – Sites should be fully operable using only the keyboard.

Guideline 2.4.3 Level A Focus Order – When navigating in a sequential order (e.g. via the Tab key), the

focus should follow the natural reading order.

Guideline 3.2.3 Level AA Navigation – Navigation should appear in a consistent and predictable order

throughout a site so users can efficiently navigate.

The Who: WCAG Guidelines – Interaction Design

Guideline 2.2.2 Level A Motion/Updates – Content that moves or automatically updates can cause issues for

those with disabilities. Ways to start and stop such activity should be provided.

Guidelines 3.2.1, 3.2.2 Level A On Focus/Input – Because it can be disorienting, changes of context should not occur

when shifting focus or choosing from a selection, but rather when the user takes a specific action to do so.

Guideline 3.3.1 Level A Errors – If an input error is detected, the error should be identified and

described to the user in a text form.

The Who: WCAG Guidelines – Interaction Design

Accessibility Usability– A website can comply with standards– A website can pass all the automated accessibility checks– A website can appear to be accessible

HOWEVER– An accessible website is not necessarily usable– Web pages can be verified accessible by focus groups, and still

be inaccessible to a third party– Individual users may have cognitive, technical, or other

barriers

The Who: Accessibility Does Not Equal Usability

Business Drivers

Minimize Legal Risk– Litigation Risk is the potential costs to an organization from

complaints, litigation costs, damages, and injunctions– Risk can come from both publicly available systems (ADA Title

III) and employee facing systems (ADA Title I)– Risk is roughly correlated to an organization’s transaction

volume– Cost to settle a class action lawsuit – including damages and

injunctive costs – typically tops $10M

The Who: Business Drivers

Conform to the Law (United States)– All US Federal Government agencies and funded organizations

must build and procure accessible Electronic and Information Technology (EIT) under Section 508

– Many US State Governments have Section 508-like requirements

– Private sector companies may also have similar accessibility requirements under the ADA

The Who: Business Drivers

Color blindness occurs when you are unable to see colors in a normal way. Most commonly, color blindness (also known as color deficiency) happens when someone cannot distinguish between certain colors, usually between greens and reds, and occasionally blues.

The Why: Visual Deficiencies - Color blindness

Men are at much higher risk for being born with color blindness than women, who seldom have the problem. An estimated one in ten males has some form of color deficiency. Color blindness is more common among men of Northern European descent.

The Why: Who is likely to be color blind?

The Why: What are the different type of color blindness?

Green weakness

Red weakness

Blue weakness

Compete weakness

• Contrast-A - A color picker application for web designers that allows users to interact with a 3-dimensional color RGB color space, examine the contrast of color pairs according to WCAG 2.0, view the results for various types of color deficiency, and create and print custom color palette

• Color Blindness Simulator - Use this tool to reveal how your images may appear to users with a variety of color blindness conditions

• WCAG Color Contrast Analyzer - determine the legibility of text and the contrast of visual elements, such as graphical controls and visual indicators.

• CheckMyColours - a tool for checking foreground and background color combinations of all DOM elements and determining if they provide sufficient contrast when viewed by someone having color deficits.

• Color Check - determines the color difference and contrast between any two colors

• Visibone - Color Deficient Vision Cheat sheets

• WhatColor – Identify the color of a pixel

• EyeDropper – Find the RGB value of any pixel on the screen

Useful Tools

• Alt text• Alternative formats• Correctly labeled links• Always follow best practices for web development

– Simplify pages (language, design, navigation)– Resizable, clear font face– Consistent navigation– Contact info– Quick loading pages– Verify code, hyperlinks, spelling, CSS

The How: Fix the easy stuff first

HTML & Headings

With the proper design, headings can be an integral part of how a screen reader user can efficiently skim through content and get the most out of navigating a website. Properly designed headings convey the logical structure and sections of a web page. Visually, headings are typically indicated by color, size, font or spacing. For screen reader users it is also important that explicit and properly ordered HTML heading elements be used to indicate any sections or headings on a page.

The How: HTML Elements and Screen Reader Compatibility

√ Use headings to define the page structure• This both creates a semantic structure for your page and it allows screen

reader users to be able to navigate by heading and jump from section to section.

<h1>MWLUG Sessions</h1> <h2>System Administration</h2> <h2>Application Development</h2>

<h3>Do you see what I see?</h3> <h3>Extreme Development: Pair Programming</h3> <h3>Hello and Welcome to NotesIn9</h3>

<h2>Innovation</h2> <h3>Design Matter 2.0</h3> <h3>Think Outside the Sphere! Box for IBM Professionals</h3>

<h2>Best Practices</h2>

√ Use CSS to style the headings• If you don't like the way the default headings look, and most of us don't, just

use CSS to style the headings.

<h1>MWLUG Sessions</h1> <h2>System Administration</h2> <h2>Application Development</h2>

<h3>Do you see what I see?</h3> <h3>Extreme Development: Pair Programming</h3> <h3>Hello and Welcome to NotesIn9</h3>

<h2>Innovation</h2> <h3>Design Matter 2.0</h3> <h3>Think Outside the Sphere! Box for IBM Professionals</h3>

<h2>Best Practices</h2>

– Your <h1> should be where the unique main content of your page begins, which usually means it will come after your navigation system.

– It is fine if your first heading on the page is not an <h1>, such as a having an <h2> come before your first <h1>

– You should have only 1 <h1> per page. If you feel you must, you can use a second <h1> for the title of your page.

The How: General Rules for Applying Headings

– Don’t obsess over making the first heading on your page an <h1>.

– Don’t pick a heading level simply for font sizing purposes. Pick a level that corresponds roughly to the outline of the page.

– It is not usually necessary to skip heading levels, going from an <h1> directly to an <h3>.

– There are always exceptions to rules. Just make sure you are breaking the rules for a good reason.

The How: General Rules for Applying Headings

– Technical:• Accessibility requirement has

been met through the use of ALT text

– Functional:• Does the word “logo” fully

convey the meaning of contents of this image?

• What is this logo for?

The How: alt Attribute - Technical ALT text

– Functional • goes beyond merely

meeting a technical requirement; actually usable by the website visitor

The How: alt Attribute - Functional ALT text

Accessible Rich Internet Applications (ARIA)

ARIA is a set of special accessibility attributes which can be added to any markup, but is especially suited to HTML.

The How: What is ARIA?

ARIA roles are added to HTML markup like an attribute. They define the type of element and suggest what purpose it serves.

The How: ARIA - Roles

The How: ARIA - Role

Banners typically includes things such as the logo or identity of the site sponsor, and site-specific search tool. A banner usually appears at the top of the page and typically spans the full width.

<div role="contentinfo"> This website was built by Roy.

A large perceivable region that contains information about the document.

Examples of information included in this region of the page are copyrights and links to privacy statements.

<div role="alert"> Please remember to fill out your

evaluations. </div>

A message with important, and usually time-sensitive, information.

ARIA attributes are slightly different from roles. They are added to markup in the same way, but there is a range of ARIA attributes available for use. All ARIA attributes are prefixed with aria-.There are two types of attributes, states and properties

The How: ARIA - Attributes

An example of an ARIA attribute that is a state is aria-checked

The How: ARIA – Attributes - States

An example of an ARIA attribute that is a property is aria-labelledby

<div id="address">Address</div><input type="text" aria-labelledby="billing address"/>

</div>

The How: ARIA – Attributes - Properties

• Use Semantic HTML Elements Where Possible– Table of document conformance requirements for use of ARIA

Attributes in HTML features

• Your Element Can Only Have One Role• Do Not Change Native Semantics

Use:• <strong> instead of bold• <em> instead of italics

The How: Rules of ARIA use

ARIA landmarks are attributes you can add to elements in your page to define areas like the main content or a navigation region. The possible landmarks are as follows.

– banner– complementary– contentinfo– form– main– navigation– search– application

The How: ARIA Landmarks

Testing Accessibility

Often times developers overlook support for the keyboard when they create custom widgets. To be accessible to a variety of users, all features of a web application or widget should also be controllable with the keyboard, without requiring a mouse.

The How: Testing Accessibility - Keyboard navigation

How should keyboard navigation work in an ARIA-enabled web application:

– The Tab key should provide focus to the widget as a whole. • For example, tabbing to a menu bar should put focus on the menu's

first element.– The arrow keys should allow for selection or navigation within

the widget.• For example, using the left and right arrow keys should move focus to

the previous and next menu items.

How should keyboard navigation work in an ARIA-enabled web application:

– When the widget is not inside a form, both the Enter and Spacebar keys should select or activate the control.

– Within a form, the Spacebar key should select or activate the control, while the Enter key should submit the form's default action.

– If in doubt, mimic the standard desktop behavior of the control you are creating.

• An often overlooked but significant aspect of website accessibility– Test

• Unplug mouse• Tab (forward)• Shift+Tab (backwards)• Enter (activate links, buttons, controls, etc.)

The How: Testing Accessibility

• Focus indicators visible via Tab– Navigation order – logical and intuitive– Interactive elements accessible via keyboard– Scripted elements and widgets accessible via

keyboard– Lengthy navigation needs Skip to Main Content,

Headings, ARIA landmarks

The How: Ensure Keyboard Accessibility

The How: Navigation Order

“If you can design a website, you can design an

accessible one”University of Washington, Do-IT

• ARIA Specification 1.0 (Last update: March 20, 2014)

– http://www.w3.org/TR/wai-aria/• ARIA Roles Model

– http://www.w3.org/TR/wai-aria/roles• ARIA User Agent Implementation

– http://www.w3.org/TR/wai-aria-implementation/• ARIA Best Practices

– https://www.w3.org/TR/wai-aria-practices/• How to meet WCAG 2.0

– https://www.w3.org/WAI/WCAG20/quickref/

Useful links

• DHTML style guide– an overview of how keyboard navigation should work for each

type of widget supported by ARIA.• http://access.aol.com/dhtml-style-guide-working-group/

• 2015 WebAIM Screen Reader Usage Survey– results of a survey to determine screen reader preferences

• http://webaim.org/projects/screenreadersurvey6/

• HHS Section 508 Accessibility checklists– The official HHS Accessibility checklists

• http://www.hhs.gov/web/section-508/making-files-accessible/checklist/

Useful links

• Wave– http://wave.webaim.org/

• Web Accessibility Evaluation Tool

• Accessibility Viewer – https://www.paciellogroup.com/resources/aviewer/

• an inspection tool for Windows that displays the accessibility API information (MSAA, IAccessible2 UI Automation, ARIA, HTML DOM) exposed by web browsers to the operating system, and thus to any assistive technology (AT) such as screen readers.

• Inspect – https://msdn.microsoft.com/en-us/library/dd318521(v=vs.85).aspx

• a Windows-based tool that enables you select any UI element and view the element's accessibility data.

• AChecker– http://achecker.ca/checker/index.php

• Checks single HTML pages for conformance with accessibility standards to ensure the content can be accessed by everyone.

• Web Accessibility Evaluation Tools List– https://www.w3.org/WAI/ER/tools/

• a list of evaluation tools that you can filter to find ones that match your particular needs.

Accessibility Evaluation Tools

Roy RumanerEmail: rrumaner@gmail.comTwitter (and most everywhere else): rrumanerLinkedIn: RoyRumanerrrumaner.blogspot.com