WCAG 2.0Level A

An Interpretation by Elianna James

Purpose of this slideshow

O Simplify WCAG until it is easy to

understand

O Develop sensitivity on the issues

O Know quickly if a site element passes or

fails

O Think logically, not reactively, on the

subject

O Understand that “guidelines” does not

mean “law”

Who’s the authority?

O No one, really.

O Many, many smart and talented and well

meaning people wrestle with Assistive

Technology (AT)

O They also wrestle with browsers,

operating systems and constant software

updates

O Not to mention spending thousands of

hours with end Users who rely on all of

the above to work together seamlessly –

see last slide

If no one is the authority, why am I listening to you?

O You don’t have to

O For that matter, you don’t have to listen to

anyone

O But your software will likely be deficient

O W3C gets a lot of credit for what I got right

here

O WebAIM , SSB BART and many others

do, too.

O Mistakes are all mine

O If a website meets these four criteria it

might “pass” the WCAG guidelinesO Perceivable

O Operable

O Understandable

O Robust

O Even if it passes, it might not be

accessible

O There’s a little factor here called human

beings. We are all a bit quirky

P.O.U.R.

Level A

WCAG 2.0Perceivable

Perceivable means “I know it is there”

O If my vision is seriously compromised I can

tell, via an audio clue or speech, there is a

button I can use

O If my hearing is seriously compromised I

can read captions and/ or see a sign

language communication to help me

understand the video I can see

O If I cannot see or hear I can get info via

Braille

Non-text Context 1.1.1

O A picture, a chart, a graphic has some text

that I can access so I can be included in

knowing what the information conveys (Alt

text)

Time Based Media 1.2.1

OPre-recorded audio, such as a podcast,

have captioning or transcription available

when User plays it back

OFor pre-recorded video, have captioning

and also an audio track, provided to User

when they play it back

OException would be a truly “silent movie”

from the early 1900s, which should have

comments explaining the on-screen action

Captions 1.2.2

O(Prerecorded media) has captions.

OAudience is people who are deaf/ HOH

(Hard of Hearing)

OCaptioning should include dialog plus

other sound elements that contribute to

the total effect (examples “drum roll”,

“brakes screeching car to a halt”, “yelling

in a crowd”)

Audio Description 1.2.3OUse dialog pauses to add audio

descriptions: info about characters,

actions, on screen text (“A billboard sign

says ‘Next exit 14 miles’ “)

O If there are no dialog pauses long enough

to accommodate extra descriptions,

provide accompanying text-based

information to augment

OLinks leading to “extra text” that are placed

near time-based media are sufficient to

pass this guideline

Summary (Perceivable)

O The first step to accessibility is whether

the User knows the content, control or

widget is there

O The full webpage must be available to any

AT (Assistive Technology) the User relies

on

WCAG 2.0Operable

Level A

Operable means “I can make it work”

OWithin my limitations and abilities I can

trigger all actions on the website

OForms can be filled out

OButtons can be used to submit my data

OVideos can be watched/ listened to

O I can send information and share it

Keyboard Only 2.1.1

OAll functionality on the page can be operated using only a keyboard or keyboard substitute; mouse use is fine, just not the only method that you can use

OKeyboard substitutes include speech input software, sip-and-puff software, on-screen keyboards, scanning software, alternative keyboards

OThis requirement doesn’t apply to drawing programs or many gaming sites

No Keyboard Traps 2.1.2OThe User cannot be trapped in some part

of the site. This means that, if you got

there by using a keyboard, you have to be

able to get out of the page section using

only a keyboard

OCalendar widget should allow users to

add, remove or update items in the

calendar

O If User gets into or is placed in a modal

they should be able to dismiss the modal

using controls in the modal itself

Timing Adjustable 2.2.1

O If there is a time limit in the site, User can

intervene and change it

OUser is warned of a pending time limit

OUser can extend the time limit

OUser cannot change time limit if it is a

legitimate feature of the functionality

(think: live auction)

Pause, Stop, Hide 2.2.2

OMoving text can be distracting, interfere

with screen readers, and cause problems

for those who don’t read quickly. Have a

method so users can pause movement

O If content is not live action then “resume”

should bring User back to where they

triggered a pause

Bypass Blocks 2.4.1

OUse “skip navigation links” so screen

reader users and keyboard only users can

skip repetitive blocks of content

OGoal is to have fewer keystrokes to get to

desired content

OScreen magnifier users can go directly to

main content or main headings of content

in which they are interested

Page Titled 2.4.2

OTo orientation themselves to a website

Users would like to have distinctive web

page titles

O If User has multiple tabs open they can

discover page differences based on titles

OSupports people with cognitive disabilities,

limited short term memory and reading

disabilities

Focus Order 2.4.3

OTo support sequential navigation, all screen elements should take focus as user moves through screen using Tab

OBest practice is to keep a navigation order that follows page presentation order; however it’s ok if a different navigation order is used but is still logical to the User

O If tree node uses up/ down, right/ left arrows then that is ok

Link Purpose in Context 2.4.4

OSupports User to understand where the

link moves User to

O If an icon and a link are attached to one

another, don’t put alt text on the icon

because the link purpose is obvious in

context

OA news article summary directly followed

by a “read more’ link keeps the link

purpose in context

Summary (Operable)

OBeing able to operate a web site is crucial to inclusion.

OThe guidelines are for Users who have limited or no vision, physical challenges that prevent mouse usage and/ or cognitive issues that need extra support to know/ remember where they are on the page

ODeaf/ HOH population not as excluded if they have vision, but people with multiple issues may be

WCAG 2.0 Understandable

Level A

Understandable means “I get it!”

O I know what will happen when I press a

button or activate a control

O I’m not surprised when the page changes

O I know what the error message says and

how to fix the problem

O I know where I am on the page

Language of Page 3.1.1

OEvery page on a site should identify its key

language by using a code snippet at the

beginning of the code

OExample: <html lang=“en”>

O If the page has significant content in

another language then code identifying it

is on the page <lang=“fr”> before and after

that content

On Focus 3.2.1

OMerely moving focus to a page element

should NOT trigger an action.

OUser may need time to decide whether or

not they want to complete an action using

this page element

O If action is completed programmatically,

(means by the program, not the User) then

User can be confused. Not good!

On Input 3.2.2

OEntering data or selecting a form control

has predictable effects

OExample: checking a checkbox changes

what that checkbox choice means on that

page UNTIL the User un-checks it

OExample: entering your name in a data

field should leave that name there UNTIL

the User changes it (edits or deletes it)

OWindows should not pop up unannounced

Error Detection 3.3.1

OAll users become aware of errors as they

occur

OError messaging is as complete as

possible so that User has enough

information to correct the error, if they

were the ones who made it

OSilent error messages are not acceptable

OError messages should be human being

understandable.

Labels or Instructions 3.3.2

OForms should all have labels

OThese input elements are forms: buttons;

input edit boxes; check boxes; radio

buttons; drop-down menus

OForm field labels are one of the easiest

things to validate via automated test tools.

If you fail to label they will catch you!

Summary (Understandable)

O As I go through a webpage I know what to

expect if I press, click, input data or

perform any other task

O If using a screen reader I will hear that

information OR it will be converted to

Braille

O Items, including error messages, will be

conveyed in human language

WCAG 2.0Robust

Level A

Robust means “Built to last”

OWhen I update my JAWS screen reader

the page still works for me

OWhen I go from browser to browser I can

still access the site

OWhen I move to my mobile device my

favorite sites join me

Parsing 4.1.1

OAny markup language used (i.e. HTML)

must be properly formed: beginning and

end tags present; elements nested

according to specs; no duplicate element

attributes; unique IDs

OAll automated test tools will capture these

issues and fail your site

OMore importantly, poorly written code may

crash your AT or at least, confuse it

Name/ Role/ Value 4.1.2

OAnyone who uses AT (screen readers, voice input systems, additional navigation or orientation mechanisms et al) expects that all screen elements will properly identify themselves to their AT

OThis includes forms, links, tables.

OAlso means that AT can tell what the “state” of the element is: open/ closed; visible/ invisible; true/ false; range of values for slider

Summary (Robust)

O Accessible code will stand the test of time.

O It will be flexible enough so that browser

updates, changes in operating systems

and methods of sharing computer data will

still allow accessibility

Not the end…O WCAG 2.0 at a glance.

http://www.w3.org/WAI/WCAG20/glance/

O WebAIM’s version

http://webaim.org/standards/wcag/checklis

t

O SSB BART compares WCAG with Section

508

O https://www.ssbbartgroup.com/reference/i

ndex.php/Section_508_versus_WCAG

Contact me

O Elianna James

O Feedback always encouraged

O Thanks for viewing!