Tip:
Highlight text to annotate it
X
>> Jared Smith: Thank you, Paul.
I'd like to thank Paul and Preety and thank Deque for inviting me to present today
on Web Accessibility Fundamentals.
We saw by a show of hands that not everybody here is an accessibility expert.
We would like you to leave with the feeling that maybe you're a web accessibility expert,
at least certainly more versed in web accessibility.
I'm going to be focusing more today on the "why" of web accessibility more than the "how"
of web accessibility, the how will come in the other sessions.
I think it's important to start maybe with a definition of accessibility,
and I think you'll see as we go along through these two days
that defining accessibility is not really that easy.
It's a very complex thing because people are complex,
and that's what accessibility is about, is about human experience.
It's about human accessibility.
This is a definition that I like: "Development of Information systems flexible enough
to accommodate the needs of the broadest range of users regardless of age or disability."
Really what we're doing this is we're talking about giving people an opportunity to get
to our stuff and giving them a chance, at least to experience the interactions,
the content that are available to them.
It's important to know that accessibility is a continuum.
Anytime somebody comes to us and says, "Oh, yeah, my website's accessible,"
that doesn't really mean anything.
Accessibility has to be quantified, accessible to whom? Accessible to what level?
So I like to view accessibility as this continuum,
which means we can always be more accessible, which by definition means
that we will always be inaccessible to somebody, and that's okay.
We need to accept that.
If your goal is 100% perfect absolute total accessibility,
in some ways you've failed before you've even begun.
But it's important that we have these definitions and quantifications of accessibility
to help us know at least where we're at along that continuum.
It's a process, and as I mentioned, it's never really fully reached
but we can reach certain measures or thresholds of accessibility along the way.
Accessibility also encourages good design and development practices.
I think for those that do accessibility, I think you really realize that,
how much it promotes good, clean code.
Supports search engine optimization.
If you think about it, Google is blind, Google is deaf, and Google doesn't use a keyword.
That's kind of the way the search engines work.
Much of what we talk about in accessibility is making content machine readable,
so the computer can take that content and present it to the user
in a meaning ful way through technologies.
By making content machine readable,
you're making it more not necessarily search engine optimizability, search engine friendly
which is our machine-readable content there.
Also supports internationalization.
When you're talking about good content, generally text content,
and that can be translated and so forth.
Also supports multiple friendly content, adaptable content, responsive content
that can be viewed by a wide variety of technologies.
And we know about 20% of the population has a disability, 1 in 5.
This portion -- most of those are age-related things,
but that's pretty notable, about 20% of the population.
Of those, about 8.5% of the population has a disability that affects computer use.
That's a pretty minimal number.
It doesn't include most users with cognitive or learning disabilities, doesn't include those
with color deficiency or color blindness and so forth.
So you might ask yourself, "how notable?"
That's often a real initial question of accessibility,
what is the real benefit to users?
You can ask yourself whether 8.5% is significant or not.
I would argue that it is for many reasons, but probably more important than that,
while accessibility focuses on people with disabilities, accessibility benefits everybody.
By making content accessible, everybody is going to benefit.
I want to take just a minute and define a term here of assistive technologies.
How many of you are familiar with that term, assistive technologies?
Okay, about half of you.
Very basically, it might be defined as a technology that, maybe due to a physical issue
or limitation, would allow someone to function in a way that otherwise they'd be unable to.
So with that definition, is there anyone here that uses some form of assistive technology,
technology that based on a physical issue or limitation, if you didn't have that technology,
you'd have difficulty fully functioning the way that you do every day.
A couple of people, a few more hands going up.
I can actually tell that there are quite a few people here
who have used some form of assistive technology.
There, we go.
How many of you -- keep up your hands, how many of you wear glasses or contact lenses?
Okay, more than half.
You guys spend way too much time looking at your computer screens, I think.
How many of you that wear glasses or contact lenses would have difficulty functioning the way
that you do if you did not have that assistive technology?
Almost everybody that raised their hand before.
So here's an interesting question.
Do you have a disability?
Maybe you haven't really considered it.
Would you have a disability if you did not have that assistive technology?
It sounds like it, maybe if you'd have difficulty functioning.
So a lot of what assistive technology does is it kind
of makes the disability irrelevant -- not totally irrelevant.
You still have to wear your glasses or put in your contacts,
but because of that assistive technology you can fully function.
That way it really doesn't matter, especially when it comes to web content.
And that's the way assistive technologies work for all disabilities.
How frustrating would it be for you to come to a website
that doesn't work with glasses or contact lenses?
That would be pretty frustrating, pretty arbitrary.
That's a lot of what we talk about with accessibility is making web content compatible
with those assistive technologies, and when we do that, the disability, whether someone's blind
and may be using a screen reader as assistive technology that takes text content
and reads it audibly to them or screen larger for someone with low vision,
maybe takes that content and makes it larger, or captions or transcripts, or keyboard
or switch device accessibility so people can interact with content using the technology
that they need, all these various text assistive technologies, and make it on web,
at least so that it doesn't matter if the user has a disability, he can still access
and use that information and functionality.
So this may be an interesting thing to think about it.
Kind of inverse to that, if you don't make your content compatible
with those assistive technologies, in some way you have disabled that person, right?
It doesn't really matter until you present that technology, that assistive technology
with something that doesn't work.
Everything else that we talk about in web accessibility makes things better
for everybody, right?
it's just good usability and just good best practices to help everybody.
Now, going back to that 8.5% of the population, maybe it's a little bit selfish,
but one way we can look at that is oh, hey, we can expand our market
to that 8.5% of the population.
Accessibility doesn't really work that way.
The web generally is not all that friendly to people with disabilities.
Those websites, those resources out there that are accessible, that's where people
with disabilities are going to go to get their information and do their shopping,
get their education, whatever it might be, because those are accessible.
There are a few people that are really seeing that vision of not only extending their market
but targeting and really marketing to that 8-1/2% of the population.
One interesting example, several years ago, they held this meeting of some of the brightest minds
in accessibility to consider the accessibility of touch screen devices.
And kind of the conclusion of this research is wow,
touch screen devices are a black hole of accessibility.
Users can not make these accessible to somebody that can't see them.
And shortly after that, Apple released a very accessible iPhone with screen reader technology built into it,
comes native with the device, and really very accessible.
It's not perfect.
There are improvements being made all the time, but it had accessibility built in,
and kind of flipped this whole concept of accessibility in general,
especially touch screen accessibility on its head.
So if you're a blind user and you want a kick-*** phone, what are you going to buy?
A phone that's inaccessible to you or an iPhone that's accessible to you?
Of course, you're going to buy an iPhone, and Apple sees that vision.
And we go to a lot of disability conferences,
and four or five years ago you see a couple iPhones, and three years ago,
everybody had an iPhone, and two years ago everybody had an iPad and an iPhone,
and last year everybody had their MacBook Pro and their iPad and their iPhone.
We're talking about people with disabilities.
We've really seen a significant shift to Apple products
because of that vision of accessibility.
And other technologies are certainly coming along.
This is a great example, I think.
And maybe it's selfish, but wow, we really can not only target this audience
but we can have significant impact in the lives of people with disabilities.
Now, we mentioned before this continuum.
Guidelines are measures along this continuum of accessibility.
We have a few measures or guidelines that we can refer to.
First we have the web content accessibility guidelines version 1.0 or WCAG or WCAG.
If someone says WCAG, that's what they're talking
about is the Web Content Accessibility Guidelines,
international set of guidelines formulated by the Worldwide Web Consortium, the W3C,
the International standards body for the web.
Now, Version 1.0 of these guidelines was finalized in 1999.
What do you think about in regards to the web when you hear 1999?
This is like the horse and buggy days of the web.
Think about, pretty much text images in very basic forms,
and that's what WCAG 1.0 reversed to, is pretty basic html technologies.
That should be your first real big red flag regarding these guidelines.
These guidelines were very check point driven.
What that means is you could look at the guidelines, you can say, oh, yeah,
my website does that, check the box, yeah, my website does that, check the box, check, check,
check, check, check all the boxes, then you can say, yeah, yeah, yeah, my website is what?
Accessible?
Not necessarily.
You can at least say it's compliant, right, it at least met those guidelines,
at least met this measure along the continuum.
And that's important to note that compliant doesn't necessarily mean accessible,
certainly not to all users.
Next along this progression came Section 508.
How many of you does Section 508 apply to you?
How many of you know that Section 508 applies to the work that you're doing?
Specifically the scope of Section 508 is the federal government, use, development,
procurement within the federal government is contingency of federal funding,
and states have come along and adopted 508.
It has a pretty wide scope, really.
It's a very basic set of guidelines.
There are 16 checkpoints that apply to web content.
Probably the most important thing you can say about Section 508 is
that you can be 508 compliant yet totally inaccessible
to end users, the very, very minimal standard.
And it was finalized in 2001, so 2001, has kind of made the Model T Ford days of the web.
Still quite dated.
Now, 508 is currently in the process of being updated.
The technical guidelines and requirements for Section 508 are being updated, and they will,
supposedly we'll see how this shapes out maybe in the next year --
I've been saying that for 4 or 5 years --
in the next year or so, generally to map or reference directly WCAG 2.0.
And in short, the current draft guidelines say if you meet the Level A
and double A requirements of WCAG 2.0,
you've met the Section 508 requirements for web content.
So WCAG 2.0 is a little bit different in the way that it works.
It's more principles-based.
It's more technology agnostic.
The idea being as technology changes the principle-based guidelines will still apply.
The hope is they'll have a longer shelf life,
they'll be relevant longer even as technology changes.
And that's very powerful.
The difficulty with WCAG 2.0 is because they're very principles-based and kind of ethereal,
you're working on errant technology, and sometimes it's hard to bridge that gap,
in doing, what does this principle-based theme tell me I need to do
with the technology I'm working with.
There's a lot I'm sure will be happening in the next day and a half, as bridging that gap
between principles of accessibility and natural, where the rubber meets the road.
So looking at 2.0, was finalized in 2008 very good set of guidelines,
probably the best formalized set of guidelines that we have,
but even in 2008 if Section 508 was the Model T Ford,
than WCAG 2 might be the Ford LTD of the web.
You laugh, I drove this car in college, and it was awesome,
at least I keep telling myself that, wood paneling and all.
So even WCAG 2.0 is maybe starting to show a little bit of age,
especially with all the innovations we're doing, especially with things like jQuery,
so just keep that in mind that these guidelines are guidelines.
Use them as tools to help us achieve true accessibility,
which is always about the end user human experience.
So your site can be compliant, yet inaccessible, right.
That can be a little frustrating.
Maybe even to make matters worse, we're hitting rock bottom.
This presentation, I promise, is you're starting
to be technically accessible yet functionally inaccessible.
Let me explain the difference there a little bit, because this is really important
to the work that you are and will be doing.
You can make something so it technically complies and is technically accessible,
but functionally the experience is very poor.
An example you might use is a very complex menu navigation system.
You can technically make that accessible so a user can use the tab key to navigate through all
of the links within that complex menu,
and you probably have a system like this on your website.
How many times would you have to hit the Tab key on your website to get from the top of the page
to where the main content of that page begins?
Now, imagine doing that with a stick in your mouth, like my colleague Gordon does.
He's paraplegic, so he uses a stick in his mouth to navigate.
Is he going to stick around and navigate, hitting the tab key
that many times to get to your main content?
Technically accessible?
Yes. Functionally accessible?
Probably not.
So there are ways that we can address this to make things functionally, truly accessible.
I always say this, but accessibility is greater than compliance.
Compliance is awesome, and I know some of you have requirements for compliance.
You can use that as a tool to get to true accessibility.
True end user accessibility is always going to be more important
and certainly more valuable than merely compliance.
So as we start to get into this a little more,
we like to say web accessibility is not rocket surgery.
It really is not that complex, especially when you understand the ways
that users interact with and use the web.
And the approach that I'm going to present -- and this is also the foundation of WCAG 2.0,
are four key principles -- Perceivable, Operable, Understandable, and Robust.
Really, if you think about it, if something is perceivable, operable, understandable
and robust, it's going to be accessible regardless of the technology.
So just a brief introduction to these principles.
Perceivable is getting content to the user's senses in a way
that they can actually start to use that content.
So for users with auditory disabilities,
this would be users that are deaf or hard of hearing,
if you have multimedia content, say a YouTube video, in a web page what does this mean?
Well, the solution is captions for video and live audio
and text transcripts for all audio content.
That will allow the user to perceive that content in a way that's useful to them.
They can't hear the audio but they could see the captions or read the transcript
and it would become perceivable to them that way.
So very simple when you consider auditory disabilities.
Two bullets.
Unfortunately it's not that easy in implementation.
There will be talks later on HTML5 and media.
This is an area where I think scripting and jQuery can be very powerful for interaction
for accessibility, is interacting with media on the web, especially with HTML5.
So that's for somebody that's deaf or hard of hearing.
How would somebody that's both deaf and blind perceive web content?
>> Braille.
>> I heard it there.
Someone said it.
>> A Braille reader.
>> Yeah, Braille reader.
Anyway, how would somebody that can't see web content and also cannot hear web content,
how can they perceive information?
They go through touch, through generally what's called a refreshable Braille device.
It's kind of like a keyboard or a device that has pins that form Braille characters
and the user can read the line of in Braille, and the characters will refresh.
And I was going to pick on you in the back left.
She actually has -- I saw it when I walked in, you have a refreshable Braille device.
Would you mind just showing that briefly?
>> Basically it has little pins.
There are 8 pins, because computer Braille has 8 dots in it,
and this is called refreshable because the pins pop and down.
It spreads across a huge keyboard input, and there are other keys to move it around.
This has Braille and speech output.
It's my little $4,000 PDA.
>> Thank you.
You know, blind people always have the coolest laptops.
They don't have screens and all this, keyboards, things like that, kind of getting away.
Anyway, that was refreshable Braille device.
It's interesting, we need to make sure we don't neglect that audience
when we consider interaction and content on the web.
When you talk about perceivability for users with visual disabilities,
primarily you're talking about blindness...
Whoa, looks like words got cut off there. You'll all be partially blind, I guess. You can't see it all. I don't know.
There will be users with blindness, low vision, and color blindness or color deficiency.
So for users that are blind, primarily we'll be using a screen reader
in reads text out of the page, and you'll be seeing and interacting
with screen readers as part of this DMAD screen reader accessibility --
very cool technology, very frustrating technology, but very powerful for individuals
with blindness or maybe low vision.
Many users with low vision will enlarge web content, so maybe a portion of the screen
so they can see that portion that will maybe enlarge the entire contents of the screen.
And this actually is an area where scripting can also be very valuable
in handling programmatic focus.
You think about that, often we have things that generate visual focus, they highlight it
or a flash or a dialogue that pops up,
and causes visual focus, causes the user to look at it.
How is someone that's using the screen enlarger or maybe navigating with a keyboard to know
that something new has appeared on the screen that is commanding focus?
Well, we can programmatically set focus to that.
That's a big area of scripting accessibility that often causes issues.
In our web page, we can enlarge just the text with our web page, or we can zoom everything.
Those are two methods of increasing text content.
So you would want to account for both of those.
Users that may increase their text size a little bit or users that may zoom everything a lot.
Some principles to remember with visual disabilities -
First, the web pages are linear.
The screen reader is going to interact with the web page, and basically read the content
of that page from left to right, top to bottom,
based on the underlying source code of that document.
So I'd like to think of it as maybe reading a web page by looking through a straw.
You really only see or hear through a screen reader one portion of that page at a time.
Screen readers do, however, allow the user to navigate through that page in various ways,
maybe navigating by links using form controls using the tab or by headings or by lists
or forms or buttons or tables or landmarks, or a lot of different ways
to navigate them that is very powerful.
So it's it's important to ask the users navigating that you provide a mechanism
for them to know whre they're at.
If your links are all "click here," and the user's navigating by links
on the page, what would they hear?
"Click here," "Click here," "Click here," "Click here."
It's really ambiguous to everybody, so you want to have meaningful links, avoid ambiguous links
that may not make sense outside of their content.
Or they provide at a minimum, some context that would allow that link to make sense,
maybe with a heading or some other structure that would help present what that link means.
Also, alternative text for non-text elements, alt-text.
This is kind of rule number one of accessibility but the screen reader can't analyze an image
and determine what the content of that image is, so we must provide a text alternative
for that non-text content that a screen reader can then read in place of the image.
I could talk probably for hours just on alternative text.
There's some signs a whole lot of art to alternative text, and certainly some guidelines
and rules that I would strongly encourage you to go out if you're not familiar with,
to take some time to learn more about alternative text, because it's probably the area
that has the most significant impact on users with visual disabilities, is missing or poor
or inappropriate alternative text or primarily poor images.
Another thing, when you come to a form and you see the words "first name" and next
to the words first name you see a text box,
you know you probably put your first name into that text box.
You know that because you've made a visual association based on the proximity of the words
"first name," which is the text box that's right next to them.
well, somebody that's blind can't make that visual association based on proximity,
so we need to make an explicit or programmatic association
between the word's first name and the text box.
We did that in HTML with the label element. It associates label text to one particular control
and you'll also be learning how to do that with ARIA, which allows you to do multiple types
of associations in between multiple pieces of text, 2:1 control or one piece of text
to multiple controls, something you can't do in standard HTML.
Also, with data tables, when you come to a data table, say a grid, maybe a class schedule,
you can look at a particular piece of data and you can visually scan up and down,
left to right, to determine what that piece of data is based on its role, we call them headers,
someone that's blind and again, cannot make that visual association,
so we need to make a programmatic association in our markup.
This associates the piece of data to its particular row in the column headers In HTML.
It's very basically done with identifying headers with the TH element,
and then giving each header a scope attribute of either COL for column or ROW for row.
By doing that it associates headers with their column or row, then each piece of data
within that data table is then associated to those appropriate headers.
And the screen reader can then identify those headers as the user navigates within that table.
We also especially want to...
Wow, that's really cut off. I'm going to try to talk and do something here at the same time. Try changing my resolutions - see if that's better.
So a good contrast.
First of all, this is important for everybody.
Everbody reads things better when there's sufficient contrast
but it's especially important for users with low vision.
Now, the Web Content Accessibility Guidelines provide a measure or threshold
for measuring contrast, and that's a very useful tool, has this really complex formula,
and you don't want to do the math.
There are tools out there, and I'm sure I think Paul will be talking
about some of the evaluation tools.
We have one in the lounge.
You just put in an rgb program a background color and it tells you the contrast ratio
and whether it passes or fails WCAG 2.0 based on the various thresholds that it has.
We also want to make sure we're not conveying meaning or content
or information using color alone.
Now, it's real important to know that common sense is vital when considering contrast.
But common sense is vital in all aspects of accessibility, but certainly with contrast.
On the screen there are various colors here.
Are there any guesses as to which of these colors
on white background meet the WCAG requirements and which do not?
>> Red and blue.
>> Red and blue.
Pass or fail?
>> Pass.
>> Fail.
>> You said they all fail?
Okay, here's the actual answer.
The top 4 passed, the bottom 4 failed.
That was a little bit weird on the projector, it was a little bit washed out.
Now, what about the two colors of gray?
There's just a little -- you can't even see the difference.
One of them passes, one of them fails.
Why? Well, because WCAG, the guidelines, draw a line.
Anything on this side fails, and anything on this side passes.
People don't work that way, right.
It's not like, oh, I can read that, great, but the other one, no,
I can't read that at all, which is it fails.
There's a huge dynamic that actual user experiences.
That's why this common sense is necessary.
WCAG defines thresholds and measures, which are very valuable,
but we want to consider the true user impact.
As an example, a heading, small piece of bold text that barely fails will have much less
of an impact than a whole section of body text that barely passes.
If it's barely passing and you're dealing with body text the impact might be more significant
than bold text that barely fails. Does that make sense?
We want to consider the impact.
If you look at something and say - I don't know if that has enough contrast - it doesn't fix it.
We're talking about all users here, and often we can implement
that type of common sense for everybody.
Also, color reliance, an example of this.
The green mushrooms listed here are okay to eat, but the red mushrooms will kill you.
Does anybody know their mushrooms well enough to attempt some of these?
You know, in all these years, I think Paul mentioned this
at Temple probably a decade ago -- all the years we've been using this example,
and no one's ever said Tylopilus is edible.
You know that thing's going to kill you.
There you go, those are the actual ones.
So this is an example of using color alone to convey information.
How could you make this more accessible without relying on color alone?
>> Off screen text.
>> Okay, off screen text.
That's maybe one, one approach.
So off screen text would maybe indicate to screen readers, and that's an important point.
If you're blind, you're also colored blind.
It's often overlooked.
The screen readers don't generally identify the color of text
to users, so if you're relying on color.
>> Subheading.
>> So there's bold, so that would be one option, maybe bold ones that are poisonous.
Again, for screen readers, user screen readers don't always identify bold,
even if you use strong or M which are used semantically for emphasis.
>> You can use strong and then put a title.
>> Title, that might be another approach again one of the issues with the title
is generally it's not read by screen reader.
[ Background noise ]
>> Data table or definition list... >>Yeah, definition list.
One way to separate them out, right, these ones will kill you, these ones are okay.
And that's probably going to be most useful for everybody.
But you can still use the color, right?
You can still use color if you want to to enhance that for these people
that can see the color, but the key is don't rely on it.
Sometimes people say - well, put like a skull and cross bones image or something in there.
So let's say we put a skull and cross bones image after Amanita
and we gave alternative text of "will kill you."
And so now a screen reader comes through and reads "Amanita will kill you Chanterelle."
Now, this actually highlights the importance of good semantics, because if you use a true list
with the list items, that image would actually be associated
within that list item and could be differentiated.
So good markup is really important for things like this.
Now, so this affects users that are blind and users
that have color blindness or color deficiency.
It affects about 7-8% of men, about .1% of women, about 3.5% of the population overall.
Most common form of color deficiencies are red-green color deficiency,
difficulty differentiating between reds and greens, which is interesting
because what two colors do we use most on the web to convey information or meaning?
Red and green, good, bad, pass, fail, stop, go, things like that.
But this can also affect users with low vision that may override page colors to view them
in a color combination that's most useful for them.
I might see blue text on a yellow background.
That's the color combination that I need, and maybe I magnify that.
So when I do that, I override all of your page colors.
So that's a whole bunch to say don't rely on color. Use color all you want-
the actual colors don't matter. What matters are those two guidelines - sufficient contrast
and you're not relying on color alone to convey information or meaning.
If you do those, the actual colors don't matter.
I don't necessarily recommend a red-green color scheme - maybe for the holidays -
but as far as accessibility goes, that's what's most important.
Next, operable.
Operable is once we can perceive content we want to be able to use it.
We want to be able to navigate and operate within that content.
This will primarily affect users with motor disabilities.
This population is very diverse, from a lot of different ways
in which a user might operate web content, using the mouse, using the keyboard,
using a mouse stick or a head wand or eye tracking, voice control,
maybe even a very basic switch device.
You can run a computer essentially with one button.
You might go through a series of choices of narrowing things down to what you want.
Takes a lot of time but can be very accessible that way.
Also I want to talk briefly here about photo sensitive epilepsy,
how you can through strobing, flashing content, cause users to have a seizure.
This is, in order to cause a seizure, has to flash more than three times per second
and has to be sufficiently big and bright.
The color red is also more likely to cause a seizure. WCAG 2.0 defines
measures for how big is too big, how bright is too bright, how red is too red.
It's really complex and confusing.
Don't worry about it.
I boil it all down to the annoying rule: if it's big, bright, and flashing more
than 3 times per second, it has potential to cause a seizure.
So don't do it.
Where we are seeing this more recently is in HD quality video.
You probably don't have homepages that flash, but it is an issue
with video, so be cautious of that.
This is not just an issue of access.
It's not like somebody can't access that content of a strobing and flashing.
You could kill them by causing them to have a seizure, so be very mindful of it.
Generally for those with motor disabilities, we want to ensure keyboard accessibility.
Even though there might be a wide variety of types of assistive technologies
that someone might use to interact with that content, most of them use
or at least emulate keyboard interaction.
So for the most part, you can use your keyboard to interact with everything that you can
with the mouse, can get the same operation or behavior, then it's going to be accessible.
I just want to make sure you don't remove focus indicators.
This means that as you're navigating through a web page, say you're using the Tab key,
you want to be able to visually see where you're at within that page, or which links
or form controls currently have focus as you go through that web page --
very important for sighted keyboard users.
Also, I want to make sure that interactive elements are clearly distinguishable.
This is really making a comeback with mobile.
When you're looking at things from here, you want to know what things you can interact with,
what things you can tap on to perform a function.
For links, we saw the underline really go out of style for a while,
and now it's really coming back into style primarily because of mobile.
It's a universal indicator that something is a link.
It is not a requirement for accessibility, the links be underlined by default,
but if they're not there is some additional contrast requirements.
There's also a requirement that the link generally become underlined
on both mouse hover and on keyboard focus.
So if users can't see the link, maybe they've overwritten your page colors they can still find
those links.
And then ensuring the logical reading and navigational order, and that's based
on the source code order of your page or document.
You can allow users to skip over repetitive or lengthy lists of links.
It would be very tedious to navigate, for instance, through your complex navigation system
on your website, you can structure the page or provide a link so the user can jump over that.
Good error prevention and recovery mechanisms.
So it's probably safe to say that most of the frustrations you encounter
on the web have to do with forms. Right?
Did you fill in everything that's required?
Did it actually work?
If there were issues or problems, what are those problems?
How did you find and identify them and then resubmit the form?
That would be really problematic for keyboard users, for screenreader users
that may not be able to visually see those issues, for users with cognitive
or learning disabilities, maybe short-term memory issues.
Inside that really consider usability and error recovery of your forms.
And give users control over time-sensitive changes.
So I brought to you today, actually all the way from Utah,
I brought you the secret of everlasting happiness.
[ Background noise ]
You'll have to go back to the slides if you want the secret to everlasting happines.
We sometimes do this on the web, though.
This is really important.
It's so important you only have 30 mintues for this test or this page has moved,
please update your bookmarks this page will automatically redirect you in 5 seconds.
Heaven forbid you give them time to actually read the message,
especially if they're using a screen reader or maybe have a reading disability,
and then allow them to perform the function.
Give the user as much control over time-sensitive information as you can.
This is particularly, I don't want to say problematic, but it's an interesting point
when we're dealing with dynamic content, AJAX, things like that,
especially things that are updating on their own without user interaction.
Some interesting approaches there that we could take in consideration for acessibility.
So watching this real quick.
This is an entrance to a courthouse.
I think it's down in Florida.
Does anybody notice anything interesting about this that might be of an accessibility concern?
>> There's no ramp.
>> Did somebody say there's no ramp?
There actually is a ramp, comes up here,
takes you right to the landing in the middle of the stairs.
And that's it.
It doesn't take you any further.
So does this provide accessibility?
No, not really.
There's something there, and somebody had a checklist somewhere -- oh, wheelchair ramp?
Yep. Got one of those.
Sometimes with accessibility, implementing accessibility partway or incorrectly
or incompletely, sometimes can be worse than no accessibility at all.
I think you could argue that that is probably worse than no ramp at all.
If I'm in a wheelchair, maybe the view's really nice from the landing -- I don't know.
You just wasted user's time to get there.
So you want to think about that, especially in the things that you're building, complex widgets
and interactions and processes, think about the entire user process,
getting them from the beginning, clear to the end.
Sometimes in multi-step processes like a check-out process,
that last page may be the least frequented on your website.
But probably the most important if you want to make any money, or that they actually pay you.
And we've seen examples of good accessibility till that last step and then it breaks down.
So consider it for not necessarily popularity or like hit counts for particular pages
on your site -- think about the process.
Another example here, kind of a little theoretical,
here we have photos to two entrances to buildings.
On the left, we have a wheelchair ramp -- you see the wheelchair sign there.
On the right we have a ground level revolving door.
It's a little bit hard to tell here, but there's actually some accessibility built into this.
There's a button right here of the little wheelchair button.
You can hit this and one of two things will happen.
One, there's sensors built into the door, and so it can actually revolve with you
if you don't slowly or quickly, it can revolve with you.
In this case, the door stops, and the right-hand side folds open.
So if you were in a wheelchair, you could actually just go right through that entrance.
So do both of these provide accessibility?
Yeah, right?
If you're in a wheelchair, you could use either of these approaches to get in the building.
Which provides better accessibility?
Kind of an interesting question.
Now, we know the wheelchair ramp provides accessibility
and there's additional benefits to that, right.
I can push my kids in the stroller up there, the delivery guy can use that.
Maybe somebody that isn't even in a wheelchair who has difficulty with stairs could use that.
But in this case, the wheelchair ramp, you can kind of tell just by looking at it,
that it was added on after the fact.
It doesn't match the color of the building, it juts out into the sidewalk,
it's maybe even a little too steep to be kind of code for wheelchair ramps.
But kind of what the wheelchair ramp suggests is if you have a disability, you go over here.
This is your way of getting into the building.
I would argue that a universally designed approach to accessibility is better.
Let's build one entrance, let's just integrate accessibility naturally
and beautifully into that.
Sometimes with web accessibility we see the approach being, well,
let's create a screen reader version or a text-only version
of the page that users can go to.
And that can be dangerous for a few reasons.
One of them certainly is potential legal issues there of segregation,
that that idea a million people with disabilities,
you go over here, just is not all that useful.
It's more difficult.
Who wants to maintain two versions of their website?
And certainly it's not very favorable for people
with disabilities, that idea of you go over here.
So let's build one thing.
And you cann do that.
If you create a truly accessible web page, you have a text only version of your web page built
in naturally into it that's fully accessible, so there's no need to do that.
So think about that in your approaches.
At the same time, we have to consider that the experiences of people
with disabilities will be different.
They may not interact with your web page the way that you do, so we don't force our experiences
or our interactions on people with disabilities, no more so than we drag wheelchairs
up the stairs to give them the experience of getting to the second floor.
We provide a mechanism for them to get there, a ramp, an elevator or something --
I don't even know what this means.
I think it's saying that the accessible restroom's upstairs, but I'm not really sure.
Just some interesting ways to think about the way that we're addressing accessibility.
Third principle, understandable, right.
Perceive content, we can interact and operate in it.
Now we want it to make sense.
We want messages to be clear and accurate.
At least some of you got that.
So this will primarily affect users with cognitive and learning disabilities.
We take all of the other disabilities -- visual disabilities, hearing, motor,
photosensitive epilepsy -- put them all together, those with cognitive
and learning disabilities will outnumber them.
It's a very, very significant portion of the population.
And it affects everybody, right.
We all want things to be easy to understand and easy to use.
So a few guidelines here: be careful with movement and other distractors.
That little animated banner ad might be mildly annoying to you,
but it may render the page entirely inaccessible to somebody
with very high levels of distractability.
By good semantic and organization, good headings and lists, things like that.
When you come to a big long web page, what do you do?
You scroll real fast and look for big, bold text, so you can get an idea
of what the content and structure of that page is.
By using true headings within your page, you can provide that same mechanism
to all users visually but also to keyboard and screen reader users that can navigate
by headings to quickly do the same thing that you do --
get an idea of content and structure of that document.
Being consistent.
Following good interaction models and patterns,
in ARIA there are design patterns -- these will be your best friend.
Get to know these ARIA design patterns.
They define, for certain types of widgets how the user should interact with them,
which means this is how you need to build it so the user can interact with it in a standard way.
Strive for brevity.
Use the simplest language appropriate to the content.
We always joke, "It's interesting, that's the longest bullet on the slide."
But be very simple.
Interesting that this is also an area that is not understandability
and cognitive disabilities, it's an area that's not addressed well
or much at all in the guidelines.
It's hard to define whether something's understandable to a particular user or not.
So this is where a lot of common sense, good testing, user testing comes into play.
We want to focus the user's attention.
You can use animation, things that jQuery UI is really good at to focus the user's attention
on that, which is most important.
That will always be the content and functionality.
Sometimes we try to focus users to other things.
Chunking or simplifying content.
One really big complex form. Is that better than --
would it maybe be better to have a 3-step process with smaller portions of a form?
There's no answer to that.
There's no one answer, right, but there is an answer for you, and that can often be determined
through common snese and through testing.
A lot of this comes down to balancing cognitive load and functionality.
Maintaining that functionality but trying to decrease cognitive load.
This is a particular concern on home pages.
Everybody wants theirs thing on the home page, right?
So you have home pages have a really high cognitive load.
A lot of functionality but really high cognitive load.
Then how can we maybe maintain that core functionality while decreasing cognitive load?
And especially on home pages, it's a gateway to our websites and often that's the area
that people with disabilities are first going to encounter and it can give a bad impression
of what they're going to experience later on the site.
On the other hand, it can be a really good impression
of "Wow, this site has implemented accessibility, I'm going to stick with it
to find what I'm really looking for."
If you consider your typical web design/web development team,
this is your typical web developer team, right.
They're corner office in white, crisp shirts,
MacBook with the Apple logo Photoshopped out of it.
This is more the typical developer team, right.
And I can poke fun.
It doesn't get much geekier than me, with their broken lawn chair and their Dell laptop.
We had somebody say one time, "Those guys aren't developers; they're outside."
Maybe there's some truth to that.
The point here is that all of you are very adept at using the web.
You're technical people.
If you're like me, I have a web browser open all the time.
That's where I spend most of my time is inside that web browser.
I have browsers in my trousers.
I carry this thing around with me all the time.
I'm very used to the conventions of using the web.
I've developed strategies for searching and scanning best content.
I don't even see those banner ads anymore.
Not everybody has developed those conventions, right? Or maybe due to disability
may not be able to utilize those types of conventions.
So it's important if we take a step outside of our own experience and take the step outside
of our box and consider how somebody else may interact or use that content.
Often our testing involves you getting out of your cubicle
and you go next store and say, "Does that make sense?"
And I say, "Yeah, it makes sense to me."
Well, they are you.
They probably have the same conventions.
This is particularly troublesome on the sites that we're working on
and building every single day, because we're so intimately familiar with them.
People ask us, "Should I do accessibility testing with people with disabilities?"
And I say, "No."
They say, "What?
Why would I not do accessibility testing with people with disabilities?"
I say, "No, don't do that."
Instead, do user testing, and include people with disabilities.
We do just accessibility testing.
We focus on instances of inaccessibility, which can be valuable, but then we might end
up fixing instances of accessibility by having a broader user experience is still very important.
By doing user testing you're focusing on broader experience,
and along the way you can identify those instances of inaccessibility,
and end up with a better product.
And consider who your audience is.
You wouldn't take -- if you did user test with me and I say, "I really don't like the blue,
maybe go with green," you wouldn't just change it to green based on the feedback of one user.
Don't do that with people with disabilities, either.
Their insights can be very valuable but consider that their own expertise, preferences, may vary.
So be cautious and careful of that.
Now, our fourth principle is robust.
Robust deals with technology strength.
It's kind of an overarching principle over the others.
It's browser compatibility and we all love to deal with browsers,
right, so it's browser compatibility.
Fortunately it's not going away, but it's becoming an easier issue for us, as both authors
and browsers focus more on following the rules of the web, following technology
and coding guidelines and standards for HTML, CSS, for following the rules
of the Web Content Accessibility Data.
It's also hardware compatibility, so considering small screen devices, adaptive,
responsive web design is great for accessibility, because it allows
or accommodates users with different types of technologies
that they might be using to present that content.
So with robustness it's certainly looking at present, it's looking towards the future.
You don't want to build something today that doesn't work in tomorrow's technologies.
It's also looking backwards.
It's how far back do we go and still address the needs of users
with various types of assistive technologies?
It's a difficult question.
You want to consider your own audience.
There's no rule for that.
There's nothing to find in the guidelines.
Usually, I recommend you define that line for assistive technologies
about the same place you do for browser support.
If you're no longer supporting IE6 or IE7,
kind of draw your assistive technology support maybe about the same place.
This becomes especially of interest with ARIA, which we'll be talking
about where it really is only supported by newer technologies.
Talk about robustness.
This is awesome for present and future technologies,
but we want to maybe consider the implications for technologies that don't support ARIA.
So those are our four principles, hopefully a good foundation, understanding accessibility.
Regardless of the techniques that we implement,
regardless of the guidelines you think about these four principles.
No matter what you do if you meet those four principles, it's going to be accessible.
And though the principles and these guidelines are very valuable, we can also use tools
to help us along in this process.
The tools are valuable, but they're never going to be a good replacement
for gray matter, for a human with a brain.
This is where the expertise that you're going to be dealing
with today is going to be very valuable.
We're going to talk about tools, all of us will be talking
about evaluation tools tomorrow and use them as tools.
They're not the end all be all of accessibility neither are guidelines.
No tool can tell you if your site is accessible.
Compliance with any set of guidelines cannot tell you if your site is accessible.
The only way to tell you if your site is accessible is by actually using it as a person.
So use these all to assist or supplement or support that human evaluation process.
Just a little shameless plus.
We have a tool called WAVE.
If you want to check that out, it's wave.webaim.org, free tool.
We also have a Firefox toolbar.
I think Paul might be talking about it tomorrow.
Just a tool that we have developed as a community service to maybe help you
with accessibility, so if it helps you in your accessibility implementation
or evaluation process, we invite you to go check it out.
Just in conclusion, I love this quote: "For people without disabilities,
technology makes things convenient, whereas for people
with disabilities it makes things possible."
For you, online banking is convenient.
You could probably still go down to your local branch and bank if you want to.
Not everybody can do that.
Online banking makes things possible, makes banking and commerce possible
for some users with some disabilities.
The power I think of scripting and particularly of jQuery is
that it allows things to be conveniently possible.
It allows us to do amazingly powerful things really easily.
And I just want, the impact that you can have in the lives of people with disabilities is
so significant, and in these two days,
I know we come out of this having done some work that'll really have an impact,
and then if you go back you can continue that.
So thank you.
[ Applause ]
>> We may have just a minute.
If there are any questions, we'll take those as we're switching presenters here.