homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Visit PubCon.com
Home / Forums Index / WebmasterWorld / Accessibility and Usability
Forum Library, Charter, Moderators: ergophobe

Accessibility and Usability Forum

Who is responsible for web accessibility?
The webmaster, the user, or the browser maker?

 7:31 pm on Jul 12, 2007 (gmt 0)

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?



 8:17 pm on Jul 12, 2007 (gmt 0)


That's an excellent link!


 8:27 pm on Jul 12, 2007 (gmt 0)

Excellent topic!

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


 2:55 am on Jul 13, 2007 (gmt 0)

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?


 4:11 am on Jul 13, 2007 (gmt 0)

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
  • usable and accessible without bells and whistles (i.e. absence of Flash, JavaScript disabled, text-only browser, keyboard-only navigation, etc.)
  • 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]

  • incrediBILL

     8:28 am on Jul 13, 2007 (gmt 0)

    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?

    Hello YouTube...


     9:01 am on Jul 13, 2007 (gmt 0)

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


     9:12 am on Jul 13, 2007 (gmt 0)

    All videos with a soundtrack must have open or closed captioning

    Fine, no more talkies for me, all pantomime...


     9:23 am on Jul 13, 2007 (gmt 0)

    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


     10:26 am on Jul 13, 2007 (gmt 0)

    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.


     10:36 am on Jul 13, 2007 (gmt 0)

    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.


     12:32 pm on Jul 13, 2007 (gmt 0)

    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. :(


     1:30 pm on Jul 13, 2007 (gmt 0)

    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.


     3:01 pm on Jul 13, 2007 (gmt 0)

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


     3:53 pm on Jul 13, 2007 (gmt 0)

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


     4:03 pm on Jul 13, 2007 (gmt 0)

    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]


     5:44 pm on Jul 13, 2007 (gmt 0)

    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.


     6:00 pm on Jul 13, 2007 (gmt 0)

    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.

    However, it doesn't translate well to blind accessibility. I need to provide a separate form for non-JavaScript users, and I'd like screen readers to be directed there as well [webmasterworld.com]. It will be a great deal less usable than the nice GM version, but will allow its users access to the full power of the system.

    [edited by: cmarshall at 6:53 pm (utc) on July 13, 2007]


     6:08 pm on Jul 13, 2007 (gmt 0)

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


     3:29 am on Jul 14, 2007 (gmt 0)

    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.


     6:11 pm on Jul 14, 2007 (gmt 0)

    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.

    JAB Creations

     3:33 am on Jul 17, 2007 (gmt 0)

    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.

    However my designs take full advantage of CSS2 positioning and all my content starts at the top of the code and the menus at the bottom (where as they are vice versa when rendered due to positioning). I throw in layers that can opened and closed. With all this going on I have made one heck of an effort to aid keyboard-only navigation. For example when a layer opens I use JavaScript to keep the tabindex in a loop on the focused area (and use opacity to fade the rest of the page to help visually give focus to the user). If the layer is opened and the visitor tabs a full cycle the browser will focus back to the layer, cycle through the layer's anchors, JavaScript will refocus the close anchor (going back up in XHTML), and then recycle back to the browser's GUI. The user can break out of this cycle simply by pressing any key other then tab when the close button has focus. When a visitor finally closes the layer JavaScript gives focus to the anchor after the anchor used to open the layer they just closed. This works beautiful in browsers that support tabindex. However I think I should detect some level of the visitor pressing the tab key and display a site keyboard navigation key to inform the user of how to take advantage of such features.

    The user is expected to use technologies that support their ability to access all parts of a page, JavaScript and a browser with an minimally acceptable rendering engine. Support for tabindex is more important then focus pseudo-element however both are important for an effective implementation. Few things can be more annoying then trying to figure out where the anchor is that you just clicked to get to something because the browser's outline is too faint...or even when there is no hover support!

    Webmasters should make an effort to make use of JavaScript to aid accessibility by testing their work out by navigating their websites using only tab and enter keys without any usage of the mouse. If they can't access all parts of the page then they either need to rethink their design implementation or adapt their JavaScript accordingly.

    Since I use JavaScript to aid accessibility and my JavaScript is modular I call similar functions via the event handlers. Using onkeypress is as important as onmouseover. I say similar because my CSS menus require JavaScript to provide access to second and third level menu items by pressing any key other then TAB. Pressing tab navigates to the next main menu...again I think I'll need to work on informing visitors of these advanced keyboard functions somehow though if a close button becomes highlighted it should not be too difficult to figure it out...after all it's an anchor too!

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

    I think I'm going to swing by the JavaScript forum again soon... ;)

    - John

    Global Options:
     top home search open messages active posts  

    Home / Forums Index / WebmasterWorld / Accessibility and Usability
    rss feed

    All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
    Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
    WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
    © Webmaster World 1996-2014 all rights reserved