Practical Accessibility

Editor's Notes

• #3: The title of this presentation is Practical Accessibility and we have less than an hour to cover a huge subject. So we’re not going to spend a lot of time on what is disability or why make things accessible. This presentation will focus on common problems and solutions. Hopefully have a little time for Q&A and leave you with some resources. We won’t cover everything, but we’ll get you started.
• #4: But some introduction is necessary… because most peoples definition of accessibility is too narrow. When thinking about accessibility most people immediately think of the needs of blind users. And that is a good place to start.
• #5: For example there are many different reasons why someone might difficulty controlling a mouse or a keyboard from paralysis to a mild tremor, and many levels of visual acuity from blindness to just having old eyes. And cognitive disabilities effect 1 in 5 people challenging their ability to parse, learn and remember information. Every person has different needs, we can’t tell you how to meet all those needs, not just because we only have an hour, but also because we don’t know your users and what they need.
• #6: For example there are many different reasons why someone might difficulty controlling a mouse or a keyboard from paralysis to a mild tremor, and many levels of visual acuity from blindness to just having old eyes. And cognitive disabilities effect 1 in 5 people challenging their ability to parse, learn and remember information. Every person has different needs, we can’t tell you how to meet all those needs, not just because we only have an hour, but also because we don’t know your users and what they need.
• #7: For example there are many different reasons why someone might difficulty controlling a mouse or a keyboard from paralysis to a mild tremor, and many levels of visual acuity from blindness to just having old eyes. And cognitive disabilities effect 1 in 5 people challenging their ability to parse, learn and remember information. Every person has different needs, we can’t tell you how to meet all those needs, not just because we only have an hour, but also because we don’t know your users and what they need.
• #8: For example there are many different reasons why someone might difficulty controlling a mouse or a keyboard from paralysis to a mild tremor, and many levels of visual acuity from blindness to just having old eyes. And cognitive disabilities effect 1 in 5 people challenging their ability to parse, learn and remember information. Every person has different needs, we can’t tell you how to meet all those needs, not just because we only have an hour, but also because we don’t know your users and what they need.
• #9: And ultimately accessibility starts with good usability. Anything which frustrates a user with full, unfettered capabilities, if that user actually exists, will doubly frustrate someone who has a disability, small or large.
• #10: One of the key questions that evaluators ask about Sakai is whether it is accessible. The best way to answer that question is to show you. So Mary, how accessible is Sakai? [Mary] Very accessible, but not completely, but it is getting even better with Sakai 2.7 Let’s show, and in the process give you an idea of how a real person with a visual disability uses Sakai. Every person uses the web differently, especially people with disabilities, and users of adaptive devices. Adaptive devices are themselves very adaptive and every user configures and uses the devices differently. However what you’re about to see and hear is pretty typical.
• #11: Mary's walk through
• #12: That was a lot to take in
• #13: let’s see if pull out a few things from that demo
• #14: Accessibility has been a pretty big priority on Sakai for quite some time. Second, if you’ve never experienced someone using the web with a screen reader before, you might have been very surprised. I used to assume that screen reader users read through a page from top to bottom to find what they were looking for.
• #15: I guess I thought that the web looked something like this to the screen reader
• #16: OK, maybe not that bad, maybe more like this it was a huge revelation for me to see that most screen reader users don’t see the a page this way at all
• #17: they scan and parse the page in a way very similar to the way that a sighted user does. They use the screen reader to look for landmarks such as headings, links, lists, and other elements, focusing on those items and then jumping (via keystrokes) to the item that is relevant to the current task or interest. But for that to work, the elements of the page must be correctly identified on the page through their HTML tags and attributes.
• #18: We as designers and developers provide every element on the page with the proper Semantics to provide meaning and context not just to the user directly but by way of interpretation by adaptive devices. If we provide the wrong semantics or we provide those semantics in the wrong way, then we make it impossible or at least a bit more difficult for the device and the user to complete their goals.
• #19: As you saw in the example the markup for the checkboxes lacked enough information to be easily accessed. But Mary was lucky, this table was otherwise very well designed and implemented. It contained a summary that provided context…
• #20: and row and column headers that allowed Mary another way to know which checkbox was which. With out those things Mary, would have been completely lost.
• #21: I’m going to back up for a moment. Because we really jumped over the basics, with a real world example of how markup allows a person to navigate the page with out seeing the page. But lets talk about when it goes horribly wrong, and sadly there are times, when it does go horribly wrong.
• #22: [Brian] This is an example from Site Info, where the red highlight, which indicates which tools were just added is completely in accessible
• #23: here’s the markup anyone see what’s wrong
• #24: OK, it is a list that is defined by text with line breaks to break up the rows and the highlight is attached to the Portfolio’s row with a class name. And classnames are arbitrary and not parsed by screen readers. A better way to convey this information would be with another list that came before the list of tools that simply displays the newly added tools.
• #25: [Eli] most tags convey both meaning and an organizational structure which can be used both by the user and the adaptive device for navigation Let’s explore some specific tags and their use and abuse
• #26: I have abused heading tags. Just thinking, ah, I’ll use the h3 instead of h2 here because the h2 looks way to big and horsey. But that’s what style sheets are for to change the look of the headings. The heading it’s self is there to define the structure of the page. It is the outline of the page. it is very important to use headings consistently on the page and between pages. And, and this is just a convention, not a rule, there should only be only one H1 on a page. The h1 should be treated as a “title”.
• #27: paragraph tags allow users to skim through a page jumping from paragraph to paragraph
• #28: [mary] is for quotes! by the wide abuse of this tag is has become meaningless but it could be very useful if it was used correctly use CSS for indenting which give you more control anyway
• #29: screen readers treat forms in a special way because forms are so important to getting things done on the web, but it is really easy, especially with new interactive technologies such as JS to by pass using real form elements but by doing so you are by passing the built in functionality of the screen reader and losing interactivity that you could otherwise get for free, a simple example is that most browsers automatically tab through form elements
• #30: screen readers treat forms in a special way because forms are so important to getting things done on the web, but it is really easy, especially with new interactive technologies such as JS to by pass using real form elements but by doing so you are by passing the built in functionality of the screen reader and losing interactivity that you could otherwise get for free, a simple example is that more browsers and ad easy tab through form elements JS opens up many opportunities for richer interactivity but you should always start with the default tags that will be picked by the screen reader and take advantage of the built meaning for example you can add a click event to any element with out a link tag but a screen reader will then not add that actionable element to it’s list of links and it will be lost to the user there is a lot more to say about how to make forms, tables, and richly interactive web applications accessible but we can’t cover it all. So before we break for questions, let’s give you some resources - Thurs Lightening Talks on labeling - Thursdays BOF on making making Sakai 3 accessible - Accessbility WG - we’re here for you (mary) - review - consult on solutions - There are many great sources of info we have pulled many of them together on the Acc WG wiki but here are four - Web AIM - Fluid Project - BBC - Mozilla
• #31: psuedo code
• #32: psuedo code
• #33: psuedo code
• #34: psuedo code
• #35: which brings us to Web 2.0
• #36: Web 2.0 as you well know opens up a world of possibilities but it also makes it easier than every to amek likfe hell for people with disabilities, but it also carries with it the ability to make things even more acessible than ever before...
• #37: let’s focus on the two primary problems with Web 2.0 using JS and CSS you can create new things, things for which there are no built-in tags and you can add elements to page on the fly, whereever and whenever you want
• #38: let’s focus on the two primary problems with Web 2.0 using JS and CSS you can create new things, things for which there are no built-in tags and you can add elements to page on the fly, whereever and whenever you want
• #39: let’s focus on the two primary problems with Web 2.0 using JS and CSS you can create new things, things for which there are no built-in tags and you can add elements to page on the fly, whereever and whenever you want
• #40: what kind of new things… sliders date pickers dialog boxes there is no <slider> tag, no built-in concept in HTML an adaptive device doesn’t know what do with it, it doesn’t know how to describe it. some day there might new HTML semantics to describe some of these things (making a cryptic reference to HTML 5), but that’s not really the point, because as soon as you add semantics to HTML for sliders, datepickers and dialogs... someone will come along and invent some other new gizmo that doesn’t have a description. So you need to add your own descriptions and context for these elements and/or provide alternative ways to do the same thing.
• #41: what kind of new things… sliders date pickers dialog boxes there is no <slider> tag, no built-in concept in HTML an adaptive device doesn’t know what do with it, it doesn’t know how to describe it. some day there might new HTML semantics to describe some of these things (making a cryptic reference to HTML 5), but that’s not really the point, because as soon as you add semantics to HTML for sliders, datepickers and dialogs... someone will come along and invent some other new gizmo that doesn’t have a description. So you need to add your own descriptions and context for these elements and/or provide alternative ways to do the same thing.
• #42: what kind of new things… sliders date pickers dialog boxes there is no <slider> tag, no built-in concept in HTML an adaptive device doesn’t know what do with it, it doesn’t know how to describe it. some day there might new HTML semantics to describe some of these things (making a cryptic reference to HTML 5), but that’s not really the point, because as soon as you add semantics to HTML for sliders, datepickers and dialogs... someone will come along and invent some other new gizmo that doesn’t have a description. So you need to add your own descriptions and context for these elements and/or provide alternative ways to do the same thing.
• #52: so what do I mean by alternative input here is an admittedly lame use of a slider control but it is easy to understand... it... but sliders are spatial controls, and to a person who doesn’t see a web page spatial controls are pretty meaningless or even for a keyboard user, who can’t drag the slider, giving that user the ability to focus on teh slider control and use the arrow keys to move the control left and right is tedious at best. the solution... provide a text box to type into! you might even chose to mark up the page in such a way that keyboard and screen reader skips the slider entirely. same for the datepicker, inherently inaccessible.
• #53: so what do I mean by alternative input here is an admittedly lame use of a slider control but it is easy to understand... it... but sliders are spatial controls, and to a person who doesn’t see a web page spatial controls are pretty meaningless or even for a keyboard user, who can’t drag the slider, giving that user the ability to focus on teh slider control and use the arrow keys to move the control left and right is tedious at best. the solution... provide a text box to type into! you might even chose to mark up the page in such a way that keyboard and screen reader skips the slider entirely. same for the datepicker, inherently inaccessible.
• #66: [Mary] talk about what the WG can do for you consulting testing and evaluation suggest solutions biweekly teleconferences participate
• #67: [Brian] The Fluid Project WebAIM - WebAIM is a great place to learn about web accessibility from the perspective of people with various disabilities, learn techniques to handle web accessibility issues, and understand the practical meaning of the various laws and guidelines. BBC's Future Media Standards Semantic Mark-up Guidelines - A great style guide to using the appropriate HTML to mark-up page content. Screen Reader User Survey - The results from this survey provides great insight into the demographics and preferences of screen reader users.