Upload
elianna-james
View
115
Download
0
Tags:
Embed Size (px)
Citation preview
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.
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
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
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
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!