This document provides an overview of the Web Content Accessibility Guidelines (WCAG) 2.0 at the Level A criteria. It summarizes the four main principles of WCAG - perceivable, operable, understandable, and robust. For each principle, it outlines the associated success criteria and what they mean to ensure content is accessible to users with disabilities affecting vision, hearing, mobility, cognition, etc. The document aims to simplify WCAG and help determine if a website element meets accessibility standards.

1. WCAG 2.0
Level A
An Interpretation by Elianna James

2. 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”

3. 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

4. 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
OWebAIM , SSB BART and many others
do, too.
O Mistakes are all mine

5. P.O.U.R.
O If a website meets these four criteria it
might “pass” the WCAG guidelines
O 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

6. WCAG 2.0
Perceivable
Level A

7. Perceivable means “I know it is
there”
OIf my vision is seriously compromised I can
tell, via an audio clue or speech, there is a
button I can use
OIf 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
OIf I cannot see or hear I can get info via
Braille

8. 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)

9. 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

10. 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”)

11. Audio Description 1.2.3
OUse dialog pauses to add audio
descriptions: info about characters,
actions, on screen text (“A billboard sign
says ‘Next exit 14 miles’ “)
OIf 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

12. 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

13. WCAG 2.0
Operable
Level A

14. 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
OI can send information and share it

15. 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

16. No Keyboard Traps 2.1.2
OThe 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
OIf User gets into or is placed in a modal
they should be able to dismiss the modal
using controls in the modal itself

17. Timing Adjustable 2.2.1
OIf 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)

18. 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
OIf content is not live action then “resume”
should bring User back to where they
triggered a pause

19. 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

20. Page Titled 2.4.2
OTo orientation themselves to a website
Users would like to have distinctive web
page titles
OIf 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

21. 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
OIf tree node uses up/ down, right/ left
arrows then that is ok

22. Link Purpose in Context 2.4.4
OSupports User to understand where the
link moves User to
OIf 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

23. 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

24. WCAG 2.0
Understandable
Level A

25. Understandable means “I get
it!”
OI know what will happen when I press a
button or activate a control
OI’m not surprised when the page changes
OI know what the error message says and
how to fix the problem
OI know where I am on the page

26. 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”>
OIf the page has significant content in
another language then code identifying it
is on the page <lang=“fr”> before and after
that content

27. 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
OIf action is completed programmatically,
(means by the program, not the User) then
User can be confused. Not good!

28. 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

29. 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.

30. 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!

31. 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

32. WCAG 2.0
Robust
Level A

33. 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

34. 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

35. 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

36. 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

37. 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

38. Contact me
O Elianna James
O Feedback always encouraged
O Thanks for viewing!