24
Architecting and Designing for Accessibility Darien Large

Architecting and Designing for Accessibility

  • Upload
    raquel

  • View
    27

  • Download
    4

Embed Size (px)

DESCRIPTION

Architecting and Designing for Accessibility. Darien Large. Agenda. How to talk about Disability and Accessibility on the Web Accessibility Guidelines Laws and Standards. Disability versus Handicap. An inability is anything a person cannot do. - PowerPoint PPT Presentation

Citation preview

Page 1: Architecting and Designing for Accessibility

Architecting and Designing for Accessibility

Darien Large

Page 2: Architecting and Designing for Accessibility

Agenda

• How to talk about Disability and Accessibility on the Web

• Accessibility Guidelines

• Laws and Standards

Page 3: Architecting and Designing for Accessibility

Disability versus Handicap• An inability is anything a person cannot do.• An impairment is a physiological disorder or

injury.• A disability is an inability to execute some class of

movements, or pick up sensory information of some sort, or perform some cognitive function, that typical unimpaired humans are able to execute or pick up or perform.

• A handicap is an inability to accomplish something one might want to do, that most others around one are able to accomplish.

“Disability, Inability and Cyberspace”. John Perry, Elizabeth Macken, Neil Scott, Jan

McKinley. August 21, 1996

Page 4: Architecting and Designing for Accessibility

Intrinsic conception of disability (inability, handicap)

• A disabled individual is one who cannot make some movement that the majority of the population can make, or lacks some sensory capacity that the majority of the population has. As a result, disabled individuals are handicapped in many ways; they cannot realistically expect to accomplish many goals that others can accomplish.

“Disability, Inability and Cyberspace”. John Perry, Elizabeth Macken, Neil Scott, Jan

McKinley. August 21, 1996

Page 5: Architecting and Designing for Accessibility

Circumstantial conception of disability (inability, handicap)

• A disabled individual is one who cannot make some movement that the majority of the population can make, or lacks some sensory capacity that the majority of the population has. As a result, an individual with a disability may need to use different means than non-disabled individuals standardly use to accomplish certain goals. Handicaps are created when the tools and infrastructure to support these alternative methods are not available.

“Disability, Inability and Cyberspace”. John Perry, Elizabeth Macken, Neil Scott, Jan

McKinley. August 21, 1996

Page 6: Architecting and Designing for Accessibility

All handicaps on the Web are circumstantial

• A handicap results from interactions between a person and their environment. But so does an ability.

• Cyberspace is the most highly mediated informative, communicative, and performative medium in human history.

• It has vastly extended the accomplishment space of everyone who is able to use it.

• Everyone requires help in gaining and effectively using information, not only those individuals who have disabilities.

Page 7: Architecting and Designing for Accessibility

That without which the Web is not accessible

Textual output and keyboard input are the sine qua non of accessibility. Without these elements, other dimensions of accessibility are difficult or impossible.– Textual output is required for access via screen

readers or magnifiers– Keyboard input is the most universal standard of

accessibility in computer applications and enables numerous other input methods

Page 8: Architecting and Designing for Accessibility

Accessibility Guidelines

Page 9: Architecting and Designing for Accessibility

Provide appropriate alternative text for images

• Convey the purpose, not the visual aspect• May be provided by textual context• alt attribute may be “” (do not omit)• longdesc attribute has been removed from

HTML5 spec (content should be accessible to all users, not just those with screen readers)

• Should be succinct and not redundant• Same image may have different alternative text

depending on function

Source: Web Accessibility in Mind, CPD/Utah State University,

http://www.webaim.org

Page 10: Architecting and Designing for Accessibility

Accessible Tables• Data tables

– Use <th> tag (scope=“row”/”col”) to indicate data table– Use <caption> tag as label– Use summary attribute for complicated tables– Avoid tables with more than two levels of headers

• Layout tables– Make visual reading order same as linearized reading order– Remove all html and read table content from beginning to

end. Does it make sense?– “Wave” validator is also great for this

Page 11: Architecting and Designing for Accessibility

Accessible Forms

• Must be keyboard accessible• Use care with JavaScript– onChange event in forms is an accessibility land

mine– Provide a submit button for menu choices instead

• Labels should be adjacent (see layout tables)• Timed responses should give user chance to

ask for more time

Page 12: Architecting and Designing for Accessibility

Accessible Links

• Links must be keyboard accessible (JavaScript: danger)

• Do not use # as a link destination• Do not use “link”, “link to”, etc. in the text of a

link– Screen readers add the work “link”

• Link text must make sense out of context (no “click here”)– Many screen reader modes alphabetize links on a

page or omit intervening text

Page 13: Architecting and Designing for Accessibility

Media Accessibility

• Captions– Text versions of spoken word– Also describe other sounds in text (sound effects,

music, etc.)• Audio Descriptions– Audio tracks that describe visual aspects of a

scene• Transcripts– Greatly facilitates reuse and SEO

Page 14: Architecting and Designing for Accessibility

Non-HTML Content

• PDF• Word• PowerPoint• Flash

All of these formats have the ability to contain descriptive markup (resembling html). Use it!

Page 15: Architecting and Designing for Accessibility

Skippable Content

• Allows users to go directly to main content• Global navigation, other repetitive elements

should be skippable

Page 16: Architecting and Designing for Accessibility

Color Vision Impairments

• Do not rely on color• 10% of general population has some color

vision deficiency

Page 17: Architecting and Designing for Accessibility

Cognitive Accessibility

• Use headings• Write clearly

Page 18: Architecting and Designing for Accessibility

JavaScript

• Use device independent event handlers (onFocus, not onMouseOver)– If this is not possible, provide redundant

navigation– onClick is generally OK, emulated with Enter

(avoid onDblClick)• Avoid onChange (use submit button instead)• Provide alternatives to JavaScript when it

cannot be made accessible

Page 19: Architecting and Designing for Accessibility

Laws and Standards

Page 20: Architecting and Designing for Accessibility

Design to Standards!

W3C WAI standards are the basis for many international laws governing web accessibility and are a high bar•WCAG (web content accessibility guidelines), for Web content developers– perceivable (multimodal), operable (device independent),

understandable (predictable), robust (future-proof)•ATAG (authoring tool accessibility guidelines), for authoring tool developers– 28 guidelines covering accessible output, prompting for

accessibility-related information, making authoring tool itself accessible

Source: W3C Web Accessibility Initiative, http://www.w3.org/WAI

Page 21: Architecting and Designing for Accessibility

WAI Continued

• UAAG (user agent accessibility guidelines), for developers of browsers, media players, assistive technologies– Access to all content, including event-triggered

content– User control over rendering– Documentation– Standard APIs

Page 22: Architecting and Designing for Accessibility

WAI Continued Continued

• WAI-ARIA (Accessible Rich Internet Applications Suite) (In Progress)– Framework for adding attributes to identify

features for user interaction, e.g., menus, primary content, banner information, etc.

– Technologies to map controls, Ajax live regions, and events to accessibility APIs

Page 23: Architecting and Designing for Accessibility

Section 508

• Amendment of Rehabilitation Act of 1973– Passed in 1986, revised 1998

• Requires that federal agencies’ electronic and information technology be accessible to people with disabilities

• Covers federal agencies and private companies that receive federal funds or are under contract with a federal agency

• Sets forth requirements significantly more lenient than W3C

Source: General Services Administration IT Accessibility and Workforce Division,

http://www.section508.gov

Page 24: Architecting and Designing for Accessibility

Resources and References

• “Disability, Inability and Cyberspace”. John Perry, Elizabeth Macken, Neil Scott, Jan McKinley. August 21, 1996 (http://www-csli.stanford.edu/~jperry/disabilities/batya/batya.html)

• W3C Web Accessibility Initiative (http://www.w3.org/WAI/)

• Web Accessibility in Mind/WAVE (http://webaim.org/)

• Section 508 (http://www.section508.gov/)