User Responsibility
April 29, 2004 | 
14 Comments
James tipped me to a very interesting document he prepared for his SXSW panel, Web Navigation Without A Guide Dog.
I’m sorry I missed the panel, because he asked a very interesting question:
If we use several accessibility techniques to “enable” a disabled user, at what point do we put the responsibility for access on the user, and not the designer or developer? How far is far enough?
It’s a tough one to answer. Especially on the Web where, ultimately, the user can have control no matter what you do. I don’t think it’s too far a stretch to say that with that control comes a bit of responsibility.
I feel that when it comes to accessibility and usability you should go as far as you can, but I do see in many cases (such as the font size widget issue we talked about a few days back) you can spend quite a bit of time working on something that really has very little benefit to your user.
I would stop short of saying we should expect the user to meet us half way, ore even 1/10th of the way. I don’t think we should “expect” a user to do anything. To do so means trouble.
But I do think there is a point, in many projects, when you can say, “I’ve done enough.”
That point will be different for every project, and for every site. Depending on the goals of the project, your resources and your (big surprise) audience, this could very greatly.
Don’t get me wrong, I think Web developers and designers should do everything they can to make their sites as accessible and usable as possible. We do have guidelines to help us when it comes to accessiblity and as far as usability goes — talk to (and listen to) your users.
User-centric goals should be a big part of your design process, but that’s not all there is to it. There are business goals, personal goals and more. Let’s face it, designing for the Web user can be a challenge, especially considering the state of our browsers and the fact that, again, no matter what you do, the user has the ultimate control.
Because of that control we have to at some point trust that we’ve done the best that we can and leave it to the user to take what we’ve given them and make the best of it.
Filed under: IA and Usability
Comments
1. Chris Vincent said:
That’s why IE is so frustrating. We’re trying to make our pages accessible, but ultimately, the accessibility problem lies on IE.
What we’ve done is should be perfectly accessible. It’s just the client reading it that screws everything up. The client is everything.
If we ever get legislation for accessible browsers, it should be required that, when a browser comes across something it can’t do, it should tell the user and point them to a browser that can. Of course, that will never happen, for several obvious reasons.
It *should* be the responsibility of the user, if they’re expecting accessibility, to use an accessible bit of software. But that’s just not the way it is. The world, as it turns out, is imperfect.
Posted on April 29, 2004 12:42 AM | #
2. Matt May said:
The best thing you can do for users with disabilities as a designer or developer is to follow established accessibility guidelines to the greatest extent feasible. That way, what you leave behind won’t have to be fixed later, which is the real pain with accessibility.
The best thing you can do for yourself as a designer or developer is to put pressure on browser vendors to follow established accessibility guidelines (see: User Agent Accessibility Guidelines, published 12/02) to the greates extent feasible. That way, you don’t have to resort to short-term hacks that are long-term bad ideas to actually help users with disabilities.
It is not all on the author. It never should be. But the “responsibility” of users to upgrade is _nothing_ compared to the responsibility of browser and authoring tool vendors to make a product that helps them. What makes more sense: 50 million users updating, 5 million authors hacking, or 5 browsers and authoring tools fixing what is known to be broken? Market pressure should be focused on getting the browsers in the game (and some are getting there) before people start pointing fingers at the user.
Posted on April 29, 2004 07:32 AM | #
3. Keith said:
Matt – Thanks for chiming in, I think you’ve hit the nail on the head (not unexpected) a few times.
When you talk about the responsibility of browser and authoring tool vendors to make products that help users with disabilities, you’re speaking to a frustration that should be shared by developers and users alike.
Posted on April 29, 2004 07:42 AM | #
4. Chris Vincent said:
Very true.
Of course, when we talk about accessibility, it almost all falls on us because the other two parts of the equation aren’t pulling their weight. IE has taken the majority of the market and the stopped developing. Meanwhile, users haven’t responsibly upgraded to Mozilla. ;) Of course, it’s usually no fault of their own–it was part of Microsoft’s plan to keep users uneducated about browsers, and it worked.
So, while we can divvy up where responsibility should go for accessibility, we’ll still have to take the brunt of the work until Microsoft gets up to speed (because Microsoft has effectively hidden the users’ responsibility from the users). Until then, we just have to do our best like Matt said.
Posted on April 29, 2004 10:06 AM | #
5. Matthew Farrand said:
It’s also down to the screen reader manufacturers. Most screen readers concentrate on old fashioned tag soup websites and go about it by trying to read what’s on the screen instead of looking at the structure of a page and making sense of the information that way.
I have had problems testing a site using a screen reader that insisted that a data table which had borders styled with CSS and a border attribute of 0, was in fact a layout table and would not read the data in any meaningful way. It seemed to choke on several CSS layout sites I visited.
Maybe screen reader software should adopt something akin to browser sniffing? If they assumed that a site with a full valid DOCTYPE was structured and tried to read it from its structure and that one without was likely to be tag soup and needed a different approach we may see real gains in accessibility.
It can be frustrating to use WAI recommended techniques designed to aid accessibility, being ignored by screen readers.
Posted on April 29, 2004 11:45 AM | #
6. patrick h. lauke said:
james’ article at the time nicely echoed my war cry of “the onus is also on the user”. in particular, i still don’t think that it is unreasonable to expect that users with disabilities should ensure that the browsing/computing environment that they use is conductive to their particular needs. to take an example, if you do require the ability to enlarge on-screen text to very big sizes, i don’t think it’s unreasonable to expect that the user, as much as the developer, has to do his/her part (in this case, by using a browser which is conductive to their needs and allows resizing of all text, or even the entire page content, such as Opera for instance). again, to re-emphasise another one of my catch phrases “you can’t blame a hammer for being a lousy screwdriver”. if you’re still using internet explorer but need to get very high screen magnification, then you’re doing something wrong. certainly, there is the element of user education…but this is something that i feel developers need no cover (in the same way that, for instance, car manufacturers are not the ones that should be doing driving tests or educating users about the dangers of driving under the influence).
anyway, i liked james’ article…until he hit the point about flash, and how users should then have a screenreader that handles it. unfortunately, that struck a very bad note with me…flash is a proprietary format, and screenreaders that handle it are certainly not cheap…it’s a world of difference between saying “you should get a free browser that offers you all these extra features you need” and “you must spend hundreds of dollars on this specific piece of software to be able to see my content”…
Posted on April 29, 2004 12:01 PM | #
7. James Craig said:
Patrick H. Lauke said:
Actually, I didn’t state that. I asked it as a question and intentionally left it unanswered to generate response. Here’s the quote:
Matt was in the panel and touched one of the main points of my argument. It’s a lot more important to lean on Microsoft (I was pointing at the W3C reps when I said this), Freedom Scientific, and other vendors who are releasing software that doesn’t correctly implement the standards. Disabled users have a hard enough time accessing the web without us adding more obstacles, though like Keith stated, there is a point on any project where you can stop and say “Ok, I’ve done enough.”
Posted on April 29, 2004 01:28 PM | #
8. patrick h. lauke said:
fair enough…i misunderstood the intention of that open question then. i stand - or rather, sit - corrected…
Posted on April 29, 2004 03:10 PM | #
9. feather said:
When you wrote your font sizing widget post, James’ article immediately came to mind. In this post, this statement really resonated:
But we, as developers, want users to do things. And the real problem as I see it, is that they still don’t know how.
My thoughts on font-sizing widgets are that they are essentially an “interim solution” to deal with the real problems:
How do we fix that? Unbury the control (what a font-size widget accomplishes), AND help users realize they can do this within their browser so that they are able to do it on all sites they want to view, not just ours. So, with the font-size widget provide a “What’s this?” link of some sort that leads to a succinct explanation of why the font-size widget is there, and what alternative mechanisms there are in the browser for accomplishing the same task.
Still a work in progress - Web User Education Guidelines.
Posted on April 29, 2004 08:52 PM | #
10. Joseph Lindsay said:
Great Idea
If everyone did this in a consistent manner (like always putting a home link on your logo or copyright at the bottom of the page) eventually it would become the accepted norm.
Posted on April 29, 2004 11:54 PM | #
11. Keith Bell said:
Let me start by saying that I consider web accessibility an important matter that deserves much more attention than it gets on the majority of sites I view. I think I have a pretty good handle on web accessibility issues and how to address them, and I endeavour to do so in the sites that I build (whether my clients understand it or not). But the “How far is far enough?” question is one that faces all of us who are trying to do our best for as many of our site visitors as possible.
And there’s the rub: a web site is like any other “product” - you can’t please (or suit) all of the people all of the time. I think we simply have to accept that there are limits as to how far it is reasonable (or even possible) for us as developers to go, before users - disabled or otherwise - have to accept some responsibility for improving their own experience. As Patrick Lauke implied, everyone needs to choose the right tool for the task, even when that task is as mundane as accessing a web site. The right tool for you may not be the right tool for me, even if neither of us is disabled (Firefox vs. Netscape 4?).
By and large, I think following the various guidelines set out by the W3C and Section 508 answers the question of how far it is reasonable to go. These guides or requirements have been put together not only with common sense in mind, but also with a thought to the kind of assistive technologies that disabled site visitors might use. But there are still some necessarily subjective elements, such as the W3C’s entreaty to “Use the clearest and simplest language appropriate for a site’s content” - which comes back to Keith’s point about taking your audience into account. A site with the topic of particle physics research frankly is not likely to be targeted at people with severe cognitive difficulties - or even people who have no such difficulties, but have no substantive background in the subject!
For a simpler example of “how far to go”, consider visual impairment. There are many people who are not blind, but whose sight is sufficiently impaired that they need extremely large text sizes on screen to be able to read - so large as I think goes beyond the responsibility of the web developer to provide through “font size widgets” or any other mechanism. People with this problem can and do accept the need to acquire large screens and screen magnifiers - or resort to a screen reader.
In most Western law, the concept of what “the reasonable man” would do holds sway. In Europe, if I run a business of more than a certain size, legislation requires me to provide wheelchair access to my premises for disabled employees, customers or other visitors. I am not, however, required to provide the wheelchair.
Posted on April 30, 2004 04:04 AM | #
12. feather said:
Matthew – you wrote:
We regularly test with screen readers, and alongside users using screen readers and haven’t experienced this. Can you point to a URL or code samples that we might be able to look at?
You have made me very curious…
Posted on April 30, 2004 04:11 AM | #
13. patrick h. lauke said:
picking up on the “screenreaders choking on css sites” theme mentioned, i’ve been silently crying big tears of frustration at the fact that JAWS seems to have an issue with the recently table-less recoded work site i made, http://www.salford.ac.uk
if the css is removed, it works fine…but as soon as the styling kicks in, performance gets extremely sluggish unless you turn off virtual pc cursor. i did some test, trying to ascertain if it’s any particular css rule that’s causing this, but the behaviour seems to be erratic and not linked to anything in particular. to be honest, it would not surprise me if this was a problem with IE not being able to cope with large css-p sites *and* exposing DOM and MSSA at the same time. even FreedomScientific have no reply so far, although we’ve quizzed them about it…
but i digress…
Posted on April 30, 2004 06:32 PM | #
14. patrick h. lauke said:
spookily enough, i’ve used the exact same analogy on many occasions in the past as well…
Posted on April 30, 2004 06:34 PM | #
Comments are now closed