|Who is responsible for web accessibility?|
The webmaster, the user, or the browser maker?
An interesting talk from accesibility expert Joe Clark: When accessibility is not your problem [joeclark.org].
|The philosophy is really simple: If a browser or adaptive technology can or should handle an accessibility issue, I won’t. |
An example given in the above article is for users of IE6 who can't resize their text - the author suggests that you can't take all the blame, you need to push some responsibility on the end user too. Accessibilty is a shared responsibility between the webmaster, the user agent (ie. browser makers), and the end user.
When do you draw the line insofar as accessibility goes? Are you doing too much?
That's an excellent link!
Personally, as long as I have ensured that I have done my part in enabling accessibility, I really don't go further.
I ensure that text can be resized ... but I don't provide tools for doing so. No little "[A] [A] [A]" on my site. (The only exception to this "rule" is sites that require registration and subsequent login. I typically offer font size (and style) as part of the user defined settings.)
I also ensure that if text is resized, that the layout doesn't break.
Other than that -- it's all general usability and accessibility. Clean markup. Intuitive layout. Usability features such as "skip links".
I'm not sure I can adhere to the philosophy as mentioned above, at least not completely. To the part referring to "If a browser or adaptive technology can handle an accessibility issue", I agree for the most part: when the tools are available, there is a definite onus on the end user to get informed and start using those tools. Unless your site is about accessibility or the tools themselves, it is not your responsibility to do the educating.
Where I start to disagree is with the "or should handle an accessibility issue" part - I don't think this is a viable option in many cases. The risk is that suggesting this approach is the equivalent of passing the blame to the tools. Your site uses eight-deep nested tables? Well, it's the screenreader's job to work out what the content is.
So, what steps are vital from the webmaster to improve accessibility, and what part can be left to the user agent and user?
Very good point.
I, too, disagree with shuffling of the "should handle" responsibility to the tools. Tools are, after all, just machines. They are not organic. They are not intelligent. By all means, many should be (and will become) much stricter in the future than they are today.
So, yes, the issue of tables nested several levels deep (as a means of controlling layout) ... The publisher of such poor markup cannot push the blame over on the tools. How is a tool supposed to know at what point to treat the various table cells as simply anonymous containers and when to treat them as true tables?
In my opinion, here's the responsibility which falls on the developer: clean and semantically logic markup (no ifs or buts or excuses here)
intuitive layout and design
use of well written content which is grammatically correct and culturally appropriate
intuitive and creative without general boundaries (don't invent a menu system which your users do not immediately understand how to use ... don't get overly creative with site search features [a site search is a site search and should be treated as such] or similar features ... links should be distinguishable ... users should always know [or easily be able to find out] where they are at with regards to site structure)
Leaves little room for accidental misinterpretation by the tools and the user, doesn't it? Well, that's how it should be. The rest is now up to the user and his/her tools of choice.
[edited by: DrDoc at 4:12 am (utc) on July 13, 2007]
I think some accessibility is fine as long as it's within reason and makes sense for the website.
So if you have a Flash site then what?
What about photo galleries?
Worse yet, stock photo galleries?
Are you required to put text for the hearing impaired on videos you post?
|Are you required to put text for the hearing impaired on videos you post? |
Yes, as per WCAG 1.0 1.1 (priority 1) [w3.org], WCAG Samurai errata [wcagsamurai.org] (All videos with a soundtrack must have open or closed captioning), and WCAG 2.0 1.1 (level A) [w3.org].
|All videos with a soundtrack must have open or closed captioning |
Fine, no more talkies for me, all pantomime...
Translation of the article into offline-language:
|Wheelchairs should be able to negotiate stairs. It is technically possible. Therefore it is not my responsibility to have an access ramp to my building. |
Translation of the article into non-accessibility language:
|People can drive cars, therefore we won't provide cycle lanes |
In the sites I do, accessibility is pretty important. The user community that uses these sites has a fairly high occurrence of disability.
However, it has a much higher incidence of lotek (in Johnny Mnemonic parlance). These are people who may not even have a high school education, and, even when educated, have a pretty low user threshold with computers.
This means that usability is even more important than accessibility, and is actually an accessibility issue, even if the WAI doesn't specifically address it as such.
My biggest efforts always go towards usability.
For accessibility, I generally do three things:
1) I try to have all my pages validate WAI-AAA.
2) I try to support older browsers.
3) No matter how fancy my site is, I provide a very usable execution path for non-cookie, non-Flash, non-JS browsing (I am currently seeing [webmasterworld.com] if there is some way to force screen readers down this path).
This is pretty relevant to me right now. I'm designing a site with a great many "bells and whistles." It will have a large amount of DHTML/AJAX, and I will need to spend a lot of time testing it and tweaking the lotek execution path.
Whenever someone claims to me that they are a "computerphobe," I eagerly give them the URI of the test site, and ask them to try it out. I then carefully note their feedback and use that in my designs.
|Wheelchairs should be able to negotiate stairs. It is technically possible. Therefore it is not my responsibility to have an access ramp to my building. |
To be fair on the author and the article, that's not at all the message I get when I read the article, and I don't think it is the aim of the author to say that. From the introduction:
|The title of this presentation is “When accessibility is not your problem” – in other words, the specific limited edge cases in which you, as a content author, do not have to worry about accessibility. I had four people in London telling me they got the impression, or feared others would get the impression, that I am claiming accessibility is not your problem. That is nonsense, of course. |
There's a certain tendancy to overdo accessibility, and treat users with (for example) a visual defect as if they also had a mental one. It's like shouting at a deaf man, or using child-like language to someone in a wheelchair: it's demeaning both to yourself and the disabled person, as well as being a desperate misunderstanding of the disability.
So no, you don't need inch-high text and a high-contrast layout with dumbed-down language to get an "accessible" badge. You can trust the disabled user and have faith in their intelligence and assume they have equipped their computers with the appropriate tools to read your site.
|There's a certain tendancy to overdo accessibility. |
Yes there is.
It basically comes down to having a complete understanding of the HTML Elements and Attributes. Most elements have an accessibility attribute involved, I use them when appropriate.
I've seen many go overboard with their accessibility implementations. So much so, that I would fail them for overdoing it. For example, excessive use of title attributes. Improper use of alt attributes, etc.
Who is responsible for web accessibility?
The site owner is ultimately responsible.
|No little "[A] [A] [A]" on my site. |
I use them with "great success". Gives me total control over layout and the visitors "do" use them. So much so that I am now making it a standard practice. If not for the visitors, for myself so I can see what the heck I'm doing. The eyesight is not what it once used to be. ;)
Can you believe there are still a "bunch" of users out there who have no clue about resizing text, none whatsoever. And, IE still does not include the Text Resizing button as a default setting. You have to dig for it and know how to add it to your toolbar. Many don't. :(
Sorry to jump back a few comments, but:
|Fine, no more talkies for me, all pantomime... |
...which helps no-one. If you put up a video and the video doesn't have captions then deaf people aren't going to be able to get the information out of the audio stream. It is therefore by definition inaccessible to them. To be accessible you must provide the information contained within the audio stream as an alternative format.
Forget about badges and levels, that's just common sense. And by removing sound you're making it inaccessible for blind users as well.
Actually, on a separate tack your audio stream should mirror the information contained within the video stream to be accessible to blind users. For example image a graph displayed in a video with no audio description; with no description of the information contained in the graph in the audio stream the blind user will not have access to that information.
|the visitors "do" use them |
Got any stats on how often they're used? I'd be interested to hear.
The counter-argument is that by providing tools that replicate browser functionality you're de-incentivising users from learning how to properly use their browser, locking every site maintainer into adding the text-size-change buttons among others (like 'bookmark me' links, print buttons, etc etc).
|Got any stats on how often they're used? I'd be interested to hear. |
I can show you "site overlays" where the number of clicks on those links is equivalent to the number of clicks on other popular links.
I can also show you "feedback/suggestions" from those who expressed their appreciation for the features.
The counter argument doesn't work for me. I've been fortunate to work in a corporate environment and was able to watch people use their PCs. After seeing that for years, I'm convinced that users need "assistance" outside of what the browsers offer, particularly IE. If the browser manufacturers would make those features "easily accessible" for the "average user", then I wouldn't have to include those elements in my designs. Although, I still would after seeing the actvity that my style switcher links get. ;)
That is interesting :)
We do include text resize buttons / zoom layouts as a matter of course, but I've always been a little sceptical. But if people use them then great!
[edited by: Robin_reala at 4:03 pm (utc) on July 13, 2007]
This is a little off topic, but I think it helps:
I think many web designers forget the advantage they gain from their huge familiarity of browser and site usage. I was fortunate enough to arrange (and witness) a user trial for some typical (in my opinion at the time) website functions. The user group was 15 Managers in a famous global corporation (I can't and darn't say which). In their non-internet lives, these people have major roles and are very successful. But they do not use the internet a fraction as much as many teenagers! Part of the process was for them to use PayPal to pay for a certain product. HALF of them had major difficulty, one was almost in tears. I walked away with my eyes much opened about what non-web-savvy people can do, (and vowing never to use PayPal on an important site).
Thats just one example, but the moral of the experience was to be VERY careful to not over-estimate how easily I think site visitors understand what they are doing.
Kapow has a very good point, and one that speaks directly to what I was saying.
People get accessibility and usability mixed up all the time. In many cases, they are one and the same, however, they can diverge significantly.
A good example of this is highly interactive content like AJAX and Flash. These technologies, when properly used, can make a page far, FAR more usable. They can make people like kapow's vict- er, subjects a LOT happier.
However, they can also introduce serious accessibility issues.
An example from the site I'm doing right now is that I am leveraging the Google Maps API [google.com] to present a search for events.
It works incredibly well. I was demonstrating it to several people the other day, and they were blown away by how natural it is. I have to tip my hat to the folks at Google. They did a great job.
[edited by: cmarshall at 6:53 pm (utc) on July 13, 2007]
|...which helps no-one. If you put up a video and the video doesn't have captions then deaf people aren't going to be able to get the information out of the audio stream |
Obviously you don't know what pantomime is (a performance using gestures and body movements without words) because there wouldn't need to BE any captions.
Of course that doesn't help the sight impaired. However, my site is all about visual arts so I'm not sure how much accessibility I can do for the visually impaired as I'm certainly not going to sit around writing detailed descriptions of every image on the site although the SEO value alone would probably make it worth while.
I know what a pantomime is: in the context of accessibility it's information presented in a single-format stream which is fundamentally inaccessible to a certain group of users (in this case blind users). I'm not saying you should have to write up every video, but you should know that if you don't a certain portion of your users won't be able to access your information. That's your call as to whether it's worth doing or not.
I'm not being argumentative and saying that you should be doing this - I'm being realistic and saying you should be aware of the problems.
Let's not detract from the point of the article (and subsequently this thread) ...
Accessibility is definitely the webmaster's/developer's/site owner's responsibility. No one is denying that. The question is just -- how far does the responsibility extend? If you are making every reasonable effort to make your site and the content thereof usable and accessible, then you have done your part (and, yes, that does include providing some form of alternate content for all important media content as well [and, yes, a textual description of the contents may suffice, provided that such description is detailed enough to highlight all the important aspects of the media content]).
It is certainly up to the user to make sure that they use the best tools available to them. A blind user is not going to visit your site using lynx. Neither is a deaf user going to use a screen reader. Let's be reasonable. But, assuming that the user uses any of these tools -- text-only browser, keyboard to navigate, screen reader, braille output, regular browser, browser with no flash or other rich media capabilities, mouse -- they should be able to access your site and its content in a normal fashion. You make your site usable and accessible. But it is up to the user to make sure they have a tool that suits their needs.
The makers of any of these tools ... Well, their responsibility lies in ensuring that they have made a tool that is as usable as possible for their target audience. Is Lynx an inaccessible user agent simply because it cannot display images? No. It's a text-only browser; and its target audience is users of text-only browsers. Is IE automatically an inaccessible user agent simply because it does not easily allow the user to resize their text? No. IE's target audience is (quite frankly) computer literate people or people without any disabilities or impairities.
It's up to you as the webmaster/developer/site owner/publisher not to design your site for a single tool. It is up to the user to use a tool that best suits their needs. And it is up to the maker of such tools to ensure that they provide the best tool possible for their target audience.
You are allowed to overlap if you so choose (take the whole "[A] [A] [A]" example) ... But no one can be expected to take 100% of the responsibility. Neither should that be your goal.
Do your part. But make sure you really do your part. And do a good job at it. That's your responsibility; and that's what the article states.
I'd personally like to see vendors give more :focus to supporting accessibility. Opera and some other browsers provide at least some focus support. Internet Explorer doesn't but at least supports tabindex.
After recently being able to thoroughly test OS X browsers I can confidently say if you're on a Mac you would be lucky to have as much keyboard accessibility on your browser as on Opera 4 save Gecko browsers on OS X. Additionally Firefox can be accessible via keyboard-only navigation if the OS X port would change some about:config value (not sure what it is). Only being able to tab between form elements is completely unacceptable.
I enjoyed working on a "Power Keys" script here in the forums to give single key access to various anchors/ids focus on a page...