The Web Content Accessibility Guidelines (WCAG) 1.0 are the W3C’s official standards for producing accessible web content. The Web Content Accessibility Guidelines Working Group does not publish information about what user research its members used to create WCAG 1.0. Similarly, many of the web’s hundreds of accessibility experts do not conduct—or at least do not cite—research that validates their advice.
After personally observing users with disabilities interacting with websites in unexpected ways, I have come to believe strongly in the value of user research—and to suspect that we really don’t know quite as much about real-world accessibility as we think we do.
The missing link#section2
Since the WCAG-WG doesn’t publicly list the studies on which its recommendations are based, I asked a reputable member of WCAG-WG what kind of user research WCAG 1.0 was based upon. He answered that “WCAG are based on many things,” which sounded good, but didn’t really answer the question. Exactly what were those “many things”?
In a later response, the working group member cited the well known NielsenNormanGroup research report on users with disabilities. The problem is that the NNG study is dated 2001, but WCAG 1.0 was published in 1999.
So we have no user research officially mentioned in our beloved guidelines, and my attempt to get this information directly from the source came to nothing. We may assume that user studies were indeed used in the making of WCAG 1.0, but we can’t examine them ourselves. Furthermore, this lack of publicly discussed research has resulted in a highly concentrated conversation about technical points and scarcely any talk about real-world user behavior.
The following examples are a few of the puzzling uses of the web that I noticed were not covered by WCAG guidelines. These experiences are merely personal observations based on only a few users, but even this limited sample suggests that current accepted wisdom on content accessibility is incomplete.
title and h1#section3
As I observed a blind web user navigate through a few pages, he reported that hearing the h1 content on top of the page was boring and redundant for him. Because his screen reader read the content of the title element first, the title element served as the actual title of the document for him, and the h1—which merely repeated the content of the title element—was useless. Of course, this was only true when the title element contained useful and pertinent information.
Given this information, a good guideline might suggest that the title element contain basic orientation information, including the name of the site and of the specific page in the site. The h1 should then be preceded by links to the main areas of the document, like “go to: content, main navigation, secondary navigation, footer,” to allow blind users to skip potentially redundant information (a repetitive h1).
WCAG doesn’t explicitly say this; the guidelines say that “repeated groups of links” should present a skip link. This may be true, but it isn’t enough, and even very rudimentary user testing uncovers a need for more detailed guidelines in this area.
What do you mean, nav should come first?#section4
The same blind user exhibited an unexpected behavior as he attempted to find a specific link on a web page. He knew information he was trying to find and expected this information to be present in the first few links of the page. As the page navigation block came after the page content, he listened to the first few links within the content and followed the one that sounded “not so bad” to him.
This is an important behavior to note, because the link the user was seeking was actually in the navigation section, below the content section. During this user’s session he never saw the nav section, because his strategy of navigation was based on the assumption that the main links should be at the beginning of the page. Much conventional accessibility advice states that page content blocks should be presented first, but some actual user research suggests that screen-reader and text-browser users expect navigation to come first. This doesn’t mean that navigation should always come first in practice, but it does demonstrate that research sometimes uncovers faulty assumptions about accessibility
And of course, content order is not covered by WCAG 1.0 at all.
Size matters, but so does boldness #section5
Another example pertains to low-vision users. A few years ago, I asked Franco Frascolla, an expert on the informatic problems of low-vision users who also has limited vision himself, to review a site I was working on.
To my surprise, Franco told me the text couldn’t be sufficiently enlarged on some areas of my site. When I tried to compare my site with others that he judged to work properly, I had a hard time figuring out what the problem was. At the default size, the text on “good” and “bad” pages often looked similar, but after a few trials, I had an insight. The problem wasn’t only the size of the text, but also the boldness of the characters at the enlarged size as seen on Internet Explorer for Windows.
Internet Explorer for Windows is the only browser that puts an upper limit on the number of times you can enlarge website text: it allows for only five levels of text size. Unfortunately, IE is the most widely used browser by low-vision users— especially the ones who aren’t informatics experts. If at the “largest” font-size the text is not large enough, then low-vision users simply cannot read it.
But more than that it turns out that while size matters, boldness also matters. In fact, a bigger text that is not bold, is less readable than a text of the same size that is bold. Compare the text in the following image and you’ll see what I mean.
Google as viewed with IE/Win with the highest text magnification allowed by that browser.
In this example, most of the text is bold or extra-bold—but not all of it. “Advanced search,” “Preferences,” “Language Tools,” and “(c) 2006 Google” are large, but not bold enough. They’re not readable for most low-vision users. And how about the button labels?
It’s easy to tell whether a particular site passes this test; review your site with IE6, choose “view > text size > largest” and ask yourself “is all my text bolded now?” Suppose that the text in the footer is larger, but not enough to become bold; then it’s not readable for most low-vision users.
Is there an official guideline that covers this very basic problem for low-vision users? Not at all. Low-vision users are covered neither by Section 508 nor by the national Italian law. Even basic user testing, though, can uncover problems like these.
The need for user research about accessibility#section6
The above examples come from my personal experience observing web users with disabilities. Are they extreme examples of users in very rare situations? Probably not, and though we don’t know exactly how many users are affected by these problems, we can assume that they’re likely quite common.
Given that the W3C has spent more than eight years discussing WCAG 1.0 and 2.0, I expected these—and probably many other common situations—to be addressed by our guidelines, but they are not.
So many experts, such little research#section7
What’s the reason for this lack of testing-centered official guidelines? I don’t think it’s because we are deliberately omitting things. I think it’s because we, as experts, are using the wrong method. How do we assess our guidelines? By discussion, for the most part. This might be a good method for many technical recommendations, but may not be the right method for establishing guidelines concerning real-life user experience. I propose that the right method would be observing users with disabilities, talking with them, and conducting both formal and informal research with them. We could document the research so that it would be replicable and publish results so that we can stop relying on dubiously researched assumptions.
Why hasn’t this been done, at least not in a visible fashion? I think it’s due to the technical background of most people participating in the discussion. Budget issues may also discourage research, but a lot of user research has been done in an inexpensive way in the past.
A sociologist might say that it could also be a matter of political issues: of power. User research is sometimes counterintuitive. The results may put in crisis some of our assumptions. We may need to reorganize our thinking and rewrite our guidelines based on real user experience.
What do we need? Testing! When do we need it? Now!#section8
Regardless of the reasons for the lack of attention to the real user experience, it’s important to start doing more user research with disabled users now. We need to improve our understanding of what’s important in accessibility, and to include this information in our guidelines. This way we can also evaluate why some surveys of disabled users seem to be so far from our expectations.
In short, we need less discussion and more user research. Especially when our guidelines form the basis of national laws, we need to ensure that they’re founded on real user experience. And in the meantime, accessibility experts, let’s conduct—and publish—more user research to support our recommendations.
I’m not an accessibility expert (yet), but after reading the article, it seems to me difficult to make search engine optimization (the white hat one) and accessibility fit together. For search engines it’s important to make the title tag different on every page and also a good description of the content. So what different information should I put into the H1 tag? Also for search engines I would always put content first, navigation to the end. How can I provide a way for blind users, to reach navigation fast? Should I place a link at the top to go to navigation?
Java Boy, I think making your sites accessible at first is good for search engines. There might be some difficulty with advanced SEO techniques, but basic site optimization for accessibility makes the content more readable for the sight disabled as well as for the bots.
As there are many different kinds of disabilities there cannot be one perfect style of making the web site accessible. I’m pretty sure that the blind have different requirements than the low-vision users.
Interesting read, Kevin. The section on boldness was a surprise to me.
Still, an obvious example of someone who puts testing first is “Jakob Nielsen”:http://www.useit.com/ .
I’ve always disagreed with content before navigation. If the reason is to read page content without having to skip navigation, then great, but now you have to skip content to use the navigation–so any benefit is arguable. And as you pointed out, it breaks convention–an important part of an easy-to-use design.
In fact, expectations would be a better word than convention.
A great article. The danger is however that the behaviour of some is extrapollated to general guidelines. If research is done, it is vital that there will be enough represents in every ‘group’ of disabilities to be able to do some number crunching (as your sociologist will probably agree on).
The challenges is of course to get homogeneous groups (that in itself is probably quite a discussion: is it on behaviour or on disability?) and to have repetitive research that can be conducted world wide.
As far as technology goed: I guess a lot of information has to be directed to user groups that they can get better tools than Internet Explorer; it should be a two way street: web site makers building better sites and people educating themselves on getting a better experience for themselves using tools available right now.
I had to work on an accessible redesign of a big payment system here where i work, we tried to do some testing and research but, as usual, time and budget skyrocketed and they dediced to cut on the testing phase (fortunately it looks like we got things quite right, since we don’t get big complaints about it from quite a big audience)…
Anyway, after reading the article, especially the part about text weight, i started wondering a little about the fact that making a site accessible to users with disabilities can be an impairing to other users: think about the bold issue, usually bold is correlated with semantic tags, like strong and headings and it’s used to put emphasys on important text in the middle of long expanses of text, to make them more readable. Now imagine a page of text with all the text bolded, it would be quite hard to read. And it would be semantically incorrect (contrasting with some of the rules in the WCAG).
Examples like the google page in the article could work correctly, but i doubt it could be considered a good general rule to always have “all-bolded” text.
One workaround could be using different media types for the stylesheet but since low-vision user usually use a normal browser this could be hard. There are tricks to read the font size and apply different styles if needed, but they rely on javascript so they can’t really be considered accessible…
I don’t know, but everytime i think about accessible design i get struck in this kind of loopholese…
Regards
Marcello
Marcello, I totally agree that semantic markup (like strong, em) should be used to used to describe the structure of a text, not to make everything bold and therefore more readable to low-vision visitors. I think most web sites are almost unaccessible for sight disabled users so they will be glad about every page that complies to basic accessibility standards. As a commercial website you have to remember the 80-20-rule…
Isn’t it pretty standard for users with visual disabilities to over-ride page styles with their own style settings? So making all text bold for example shouldn’t be an issue.
Very good article. I am in complete agreement on this. It’s truely a hinder that there is so little information available on accessibility. It is a big hinder in developement. Guidelines, all nice and well but a conclusion is nothing without the research it was build upon. As developer it is nearly impossible to make our own judgement based upon a conclusion.
Chris, you’re right, i didn’t consider that possibility.
Probably it isn’t the “correct” solution to the problem, it’s more of a workaround, but it could help (plus i doubt a really correct solution exists).
As some browsers let the user choose from different CSS one could publish a slightly different CSS containing only the “bolding” statements and let the user switch.
Regards
Marcello
Just a clarification about the text-size issue: you don’t have to have bold text all around *at normal text size*. What my case pointed out is that you just have to:
* review your site with IE6, choose “view > text size > largest”? and ask yourself “is all my text bolded *now?*”?
At the *largest text size*, all pieces of text should be bold, not at the normal size. In fact, in the google example, the text that is bolded at normal size, is double bolded at largest size. I hope this makes the point clearer. It’s not a markup issue, just a matter of rendering.
Martin: Sure, you have to check different groups before generalizing. This just shouldn’t prevent us from starting even with small groups, to see what’s really going up. The more test you do, the better. And I claim that we should publish the results, so that everyone could check with other groups, and discuss based on true data, not only on opinions. That’s really important when talking about user experience, and I still see too little research, both formal and informal, published in this field! 🙁
Good article. We do need more testing with disabled users, I am in total agreement. We have discovered so much from real user testing. Some of these findings have led us to disagree with WCAG guidelines.
We are going to publish a related post later today on one of our findings related to including default, place-holding characters in edit boxes and text areas.
One problem is persuading clients to pay that little bit extra to carry out this research. Remote testing is one solution but there is still a cost.
It feels like some commenters have misinterpreted the part about text appearing bold.
If you resize the text of f.ex. ALA twice with FF 1.0.7 (which I’m using) most of the text in the main content will appear to be bold while not actually being marked-up as bold. The headers requires resizing three times before appearing bold.
So it’s not about actually marking text as bold but making sure the font/font-size relation produces the desired effect when resized to the largest extent in primarily (our favorite browser) IE.
I’m sure though that this approach will produce a lot of headaches when you’re trying to implement it with all the different fonts in various browsers on different OS:es….
Cheers
I guess reloading doesn’t help when comments move on to the next page. Didn’t mean to repeat the authors comment.
What Maurizio describes as a problem of “boldness”? almost certainly is not. You can’t just turn the Web into bold type. As he explained, the problem is that IE/Win doesn’t zoom the fonts large enough. The bigger the fonts, the wider the stroke width, which overlaps with “boldness”? but isn’t the same thing. I don’t believe, and have seen no research claiming, that boldness has more of an impact on low-vision readability than size and spacing. This could easily be tested. As it stands, Maurizio misstates the problem.
bq. This just shouldn’t prevent us from starting even with small groups, to see what’s really going up. The more test you do, the better.
Maurizio: I agree that a bit of testing is better than not testing, but – and this is a very big but – the danger is that general rules are deducted from very limited testing. Everyone who has done any sort of scientific research at one stage knows how skewed results can be, and we could make things even worse than not knowing at all. This is a serious danger. There is a reason why scientist always quarrel about methodology.
bq. And I claim that we should publish the results, so that everyone could check with other groups, and discuss based on true data, not only on opinions.
Yes! that is an excellent point you are making and one I wholeheartedly subscribe to. It is so obvious and it is a wake-up call to all of us to what the value of ‘general rules’ really is at the moment and where the shortcoming are. As such, I think your article hits the nail on the head.
bq. I’m not an accessibility expert (yet), but after reading the article, it seems to me difficult to make search engine optimization (the white hat one) and accessibility fit together. For search engines it’s important to make the title tag different on every page and also a good description of the content. So what different information should I put into the H1 tag?
It is important to make your sites accessible, but there will be times when making it perfect for, eg screen readers, will give a poorer experience for other users. The title/H1 debate is a good example of this. For websites to get good positions and visibility in search engine rankings, they need descriptive titles and H1 elements. For them to be useful to users, the title needs to be descriptive so that it can be found in a list of bookmarks or on the taskbar. The page needs an H1 so having arrived at it, the user can see what it’s about.
Yes, in this case it will mean that a screen reader might have similar or the same brief bit of text read twice – that’s a very small price to pay for the benefits of including both. I suppose you – or _they_ – could set H1 to display:none in an aural stylesheet if you are that bothered about it.
bq. Also for search engines I would always put content first, navigation to the end. How can I provide a way for blind users, to reach navigation fast? Should I place a link at the top to go to navigation?
Yes, a hidden “skip to navigation” link is a good idea – or a link to a sitemap might be better.
Do screen readers read elements, eg home/next etc? If so, including them would be a good solution to the problem.
Why point the finger at only content creators and web developers? Why not look to the creators of browsers, screen readers, etc. to make their functionality better address the needs of the disabled users needing accessibility measures?
And yes, testing is always a great way to get information on the accessibility of a site, but only when you’re testing the content, and not the abilities (or lack thereof) of the user agent used to access the content.
Seems like one of the biggest problems we encounter is clients who are willing to pay for testing. Maybe we need to improve how we’re explaining the benefits? Many of our clients seem content to have a website that looks good in a couple of browsers but they aren’t very concerned with accessibility, at least when they learn it takes more time and money. We just try to build things right from the get-go while staying within their budget. Great article.
bq. Much conventional accessibility advice states that page content blocks should be presented first, but some “actual user research”:http://www.usability.com.au/resources/ozewai2005/#section16 suggests that screen-reader and text-browser users expect navigation to come first.
I suspect you forgot to read the “actual user research until the end”:http://www.usability.com.au/resources/ozewai2005/#section37 (slide 37).
Hey, I’m glad the community is being invited to do some user research. There is a sometimes fanatical want to have a clean markup that does not really increase accessibility. It’s just assuming that standards (XHTML + CSS) are the good thing.
bq. Hey, I’m glad the community is being invited to do some user research. There is a sometimes fanatical want to have a clean markup that does not really increase accessibility. It’s just assuming that standards (XHTML + CSS) are the good thing.
I think you are confusing a few concepts here. You can make accessible and inaccessible sites using HTML4 or XHTML. Stripping out the layout from the markup makes things better in any case, at least giving the (theoretical?) possibility to use an alternative style catered to any specific audience, but still you can make very inaccessible sites using CSS. Or very accessible ones.
Paper (in PDF form) of observation of users working with screen readers, with recommendations.: http://www.redish.net/content/papers/InteractionsPaperAuthorsVer.pdf
I have fairly recently attended a presentation done by “test partners” (testpartners.co.uk) and learnt quite a few interesting things.
These are my notes, so some people may disagree or have better opinions.
Also, really sorry for the length of this post (and remember you should always test!)…
—————
– Users only see the content in a linear fashion, have no idea of left and right (visual representation).
– Most users do not change default settings (they use multiple computers and are scared of breaking them).
– Sometimes a screen reader might skip content that is perfectly visible (bugs?) and need to be manually checked.
– Do not refresh a page automatically, the screen reader probably has not finished reading the content yet.
– Avoid ASCII art, even something as simple as “::” can be distracting.
– Avoid long words which might by difficult for a screen reader to pronounce.
– Providing an “accessible alternative” version of the page is usually ignored as they are usually out of date.
– The site map is a fail safe just incase the normal navigation bar cannot be understood or used.
– PDF content can rarely be made accessible. It is still nearly always easier to convert to HTML.
– Do not use visual attributes to convey meaning (e.g. do not use a table cell bottom border to show a divide line in a calculation).
– JAWS has poor JavaScript support, but it still ignores the
– The title attribute (title=””) on most tags are ignored by default.
– Abbr tag is ignored by JAWS (again title attribute), first time the abbreviation is used, it should be written in full (abbr in brackets).
– Do not expect something to be written in caps to be spelt out, sometimes it might try to pronounce the word.
– If you have an image (e.g. company employee) with their name printed afterwards, set the alt to blank (no point repeating the name twice).
– Access-keys are rarely learnt and frequently interfere with normal shortcuts (e.g. “alt” followed by “0” and “233” is for the e-acute).
– Users frequently use the [h] key to skip between headings (quick page navigation).
– Users can quickly skip to the next “edit field” (perhaps looking for a search field) by pressing [ctrl]+[e].
– Search results are naturally difficult to use as by there are all very similar (helps putting the results in an
)
– Users take a risk by following links, so they like to be sure, instead of just guessing (to avoid getting lost).
– Users can pull up a list of all the links on a page (can be sorted by the source, or alphabetical), so use meaningful text (not “click here”).
– Avoid foot notes (e.g. “*”), as the user will have to decide if they should risk looking for the relevant foot note (anchor links can help though).
– Navigation bar should be consistent, do not remove links, re-organise or move the nav (might appear to be a new site).
– On entering a page, a list of links is presumably a navigation bar… but an off-screened
should help avoid confusion.
– Sub Navigation should not use nested
‘s as the user is unlikely to listen to the nav on each page AND notice the differences.
– Bread-crumbs are difficult to understand especially when they use the “>” character. Although they are easier with “you are here” starting text.
– Do not use a
Woops… sorry, can someone clean up my previous post, the preview function did not work.
Lets pretend that this is a perfect world for a second and assume that you do the following.
1. You make the text resize according to the visitors browsers.
2. The text gets bold for the visually impaired.
3. All the images and h tags have alt tags to them.
Heres the concerns.
1. How will all the bolded text look to a person whos not visually impaired?
2. Will the text get too big and run over the images on the page making it look out of balance?
3. And will it make a difference if a visitor is using their own style sheets to view pages.
These are all concerns that id have plus, what if your client wants a cheap website built real fast? Will you eat the extra cost that it takes to put the time in to build the site?
Another issue that he did not mention that a sight impared friend of mine has is that he hates pages that are white. Although he needs good contrast putting his face close enough to read the text also makes the white background glare and tire his eyes out pretty quickly, especially if there is a lot of text to read.
The problem is something that we know and can recomend some changes to a client but far too often a client will want what they want regardless unless they are directly targeting people with sight problems.
bq. Another issue that he did not mention that a sight impared friend of mine has is that he hates pages that are white. Although he needs good contrast putting his face close enough to read the text also makes the white background glare and tire his eyes out pretty quickly, especially if there is a lot of text to read.
I suspect for every user that has problems with a white background you will have someone with a problem when you use a dark background. This is what I mean by extrapolating the experience of a single person into generalised rules.
If you are a real friend, I would point out to him that he probably better use the Opera browser, which has as standard a black-white or white-black user scheme built into the browser.
Also, if you could help him to tune a perfect user-defined stylesheet for him, he would probably have a much better experience all together. This is what I mean with a two way street: users should also be educated on the possibilities that are right here right now to use. The truth is, that someone must tell him that it exists.
Web site designers should provide the means and hooks to be let the user utilize a user-defined stylesheet, without breaking the standard layout and without putting up barriers for a user-defined stylesheet.
The main crux of the article, to me at least, is to user test sites. This is already mentioned within the guidelines – sorry reference is eluding me at present. However there are a lot of web designers out there designing for small to medium businesses that cannot afford the extra cost to get their sites tested in that way.
Unless a large organisation funds comphrensive testing, and publishes those results, it is unlikely that the small developers will ever get their sites user tested. So they have to use what they have learnt over time and trust their instincts.
If results are published it would have to state what disabilities the testers had, and how many of them were involved. You can’t really judge things on a small sample.
Regarding Low Vision users specifically, all of the ones I know also use a screen magnifyer, how does that affect things? I would hazard an educated guess that they don’t care if text is bold or not.
Presumably this means at the beginning in the source code. Style sheets can place the navigation anywhere on the page as the design requires but keep the navigation near the top in the source code.
Nice discussion. I hope some clarification (other than “what I already said about text size”:http://www.alistapart.com/comments/workingwithothers?page=2#11 and boldness in explorer) could make some point clearer.
* Even if user research is hard to be done properly (I agree), what’s important is to start doing it. Both formal and informal research are good, until you publish results and method used, with enough detail to let other discuss, replicate, criticate and debate. Bad research can lead to a better research. No research at all can only lead to nothing.
* It would be a little paradoxical not to do research because it is difficult to do properly, but trust on guidelines that doesn’t cite user research!
* I’m not suggesting to take all my points literally. They are real examples not covered by guidelines. They demonstrate that guidelines are not perfect, and that we need user research to improve them. Not only experts opinions.
* I’m not suggesting that every webdesigner in the world should do user research for every little project. I’d like, but it’s impratical. I suggest that people that develop accessibility guidelines (and people that can collaborate) start doing, and publishing, and citing user research. It’s really important. I think it’s even more important if we make national laws based on these guidelines.
* Finally, given all those things, well, yes, I personally think that less fanatical attitude about wcag, and markup, and all that sort of thing all around the world should be better in general, because maybe we don’t know all that much about accessibility as we thought. But that is another story! Luckily no fanatical attitude showed up here!
Really intersting article and a topic I’ve been thinking on for a few months now.
One thing that I haven’t seen in the comments (and I’ll admit I didn’t read them all) is that just as with usability testing, accessibility testing should be done against your _intended audience_. Making sure that your site works great for blind users means very little if the content of your site is targeted at kids with learning disabilities.
This is why I think the _G_ in WCAG is so important. The W3C relesed the WCAG as guidelines, not hard and fast rules that must be followed at all cost. This is unlike the Section 508 law we have in the U.S. that is followed to the letter by paper pushers with checklists. Most of them don’t understand that accessibility isn’t about making sure you have ALT tags for your images, but making sure that your site is usable and content is accessible.
Great article. Considering SEO I think it is not a big problem if navigation comes first, as long as your markup is semnatic and slim. If putting the navigation first is not possible, skip links at the top (and anchors the bottom) of the page are the way to go imho.
bq. Unfortunately, IE is the most widely used browser by low-vision users
I am really surprised reading this. Can I ask where you got that info from? It is urprising, because IE up to version 6 does not allow resizing of text that is specified in pixels at all. So a majority of sites would always stay fixed at the 10,11 or 12px font size they use, no matter which font size you choose in your browser.
Luckily, the font resizing problem will be no issue anymore once IE 7 ships (supposingly next week) that does page sacling instead of font size scaling (similar to what Opera is doing). My assumption (no, I do not have proof for this) is, that disabled people would be much more aware of using the right tools for their needs(similar to using special tools (e.g. a magifying glass for reading the newspaper) in the real world.) Does anyone have some valid data on this to prove me right or wrong?
bq. WCAG doesn’t explicitly say this; the guidelines say that “repeated groups of links”? should present a skip link.
Which WCAG are you referring to? 1.0 or the current draft of 2.0? Which guideline? There doesn’t seem to be anything in 1.0, so I assume you’re silently referring to WCAG 2.0 SC 2.4.1
bq. 2.4.1 A mechanism is available to bypass blocks of content that are repeated on multiple Web units.
Notice that this does not equate to “provide a skip link”. Marking up links as part of a block in the markup itself (e.g. following the common practice of having a navigation as an unordered list) satisfies this criterion as well.
bq. screen-reader and text-browser users expect navigation to come first
That’s probably due to their experience with the majority of other sites. I agree that the assumption, often followed without evidence, that content must come first is misguided and goes against user expectation.
bq. Suppose that the text in the footer is larger, but not enough to become bold; then it’s not readable for most low-vision users.
Most low-vision users? I’d say that’s a bit of a generalisation based on feedback given to you by just ONE expert. What about those using magnification software (or magnification/zoom functionality built into their OS)? And, considering that whether or not a font scales up to “bold” appearance is dependant on the OS, browser, font-smoothing/antialiasing, dpi and other font choices and settings of an individual’s machine, how can this bit of anecdotal advice be of any use to developers? Additionally, let’s not forget that part of the onus of accessibility needs to lie with the users: if they use inadequate products, then there’s only so much that developers can and should do, imho.
Andreas: sorry, I dont’ have official statistic for disabled ones, but I follow some disabled italian mailing lists, and, for what it counts, I often heard of disabled people that were using IE, and be totally unaware of Firefox or other browsers. Talking with them and visiting some institutions where they are educated, I had a confirm that only a minority of them (at least in Italy) knows and uses alternative browsers. The reason I think comes from some observations:
* we know that “most users”:http://www.w3schools.com/browsers/browsers_stats.asp use IE.
* Alternative browser are usually used for the most by informatic “expert” or “techno-literated” people.
* Disabled users usually are not informatic experts. They try to use the computer as is (sometimes with some expensive assistive tool…), and only proceeding they come to discover better free tools!
It’s something we, as professional, usually don’t take into account, even for basic audience. This surprised me, too, when talking with disabled people.
Patrick:
about skipping link: Looking into wcag 1.0 techniques you will “find this”:http://www.w3.org/TR/WCAG10-HTML-TECHS/#group-bypass , where one of three method indicated is “include a link that allows users to skip over the set of navigation links”. Simply marking a group of links seems not to be enough according this document. There is the “until user agent” issue, here, that we already know, but…
About the “most low vision user”, well, obviously all those that don’t use magnification tools. There are a lot of them. The low-vision users form a large and fragmented universe, as they Franco Frascolla and other experts told me, so a bit of punctualizations may help.
Anyway, again, the extent of these observations can only be assessed by user research! That’s the main point. I’d like very much to know how many users have this or that problem. I ask myself and to my gentle audience: is it possible that we write accurate guidelines without knowing a little more about that?
And finally, Justin:
bq. The W3C relesed the WCAG as guidelines, not hard and fast rules that must be followed at all cost.
I totally agree. But we are at the point in history where, in Europe, many national laws are being done / have been done based upon wgag. They assume that wcag-wg exactly knows what it’s talking about. I have no reason to think it doesn’t. But after all these years, I note a surprising lack of documentation about user research, and some evidences that guidelines don’t cover all.
I hope you see why I wrote this article, now. It’s really needed that we observe users and publish our researches to improve guidelines, especially if they become laws!
Research into the application of accessibly designed sites is impeded by the state of flux in the technology and the politics attached, it being seen as a ‘handicapped thing’ rather than an expression of the “world wideness” of the internet, and that these matters do not sit well in a context of the present views of meaning and learning being developed in conjunction with the developer and the user/student.
Usability may be seen as a set into which accessibility is a major element. However refining the contexts of what is understood by what are, at times esoteric debates, is part of the development of the questions that are to be researched.
The debate (some my say cat-fight) over the new standards in WCAG 2.0, reflect the second point I raised, in which accessibility is being moved from a series of absolutes, to recommendations – I accept that this may be a simplification, but it places the Australian DDA (Disability Discrimination Act) in an interesting situation, moving from WCAG 1.0 as its desired standard for online presentation. With all its shortcomings, it did however present something that the non-technologically literate could use as a standard on which to cling and defend.
I could go on, but I think the tenor of my position is clear. The process is in motion, and time, respectful communication and patience will bring it to its conclusion.
Quick response on Chris’ (?) comment on the first page about users with low-vision that would over-ride the page with their own stylesheets. In my experience, most web visitors with disabilities are not computer savvy. That is, they know how to use their computer, but not the finery of defining new stylesheets, or using the browser based tools to make page viewing easier on them. This is of course a generalisation.
I say this from a perspective of having worked in the disability rights and services field for over a decade and assisted literally hundreds of people with computer usage. And my experience is anecdotal rather than scientific 🙂
I’d also say that people with disabilities have a right to access, but a duty to understand the tools at their disposal better. Web designers should not have to reinvent the wheel to replace easily accessible/usable functions of their web browsers.
My 2 cents 🙂
bq. 1. How will all the bolded text look to a person whos not visually impaired?
I think there’s some confusion out there. No-one is saying that we should make the text *bold*. If you look at the screenshot of Google’s homepage in the article, you can see that some of the links look bolder than others – but they are all on font-weight:normal.
The reason for this is that normal text will look ‘light’ up to a certain size, as it still has 1px wide strokes – but above a certain size, main strokes will be thicker, and will make it look bolder, and easier to read for people with poor eyesight.
The problem is that IE (how many times have we heard those words…!) will only let you resize the text a certain number of times. So if the text is small in the first instance, you *can’t* resize it enough to give it the extra weight.
Other browsers let you enlarge the text far more, so this is not a problem.
bq. 2. Will the text get too big and run over the images on the page making it look out of balance?
This is something that you should test for, using different browsers. Hopefully it won’t, but it depends how you’ve set your document up. CSS _ought_ to handle this better than tables, but it depends how it’s been used.
bq. 3. And will it make a difference if a visitor is using their own style sheets to view pages.
Your page should be useable without any stylesheet applied – otherwise, how will screenreaders and search engines make sense of it? If the basic, unstyled page is OK, it shouldn’t be a problem for users to overlay their own stylesheet on top.
If they’re doing this, it’s reasonable to assume that they are moderately competent and won’t have done anything dramatically stupid that they can’t resolve for themselves. You have given them a page that they can interpret/render in whatever way they want to – the ultimate goal of web design!
As an aside to this article, I would like to point to a good example of user research-based accessibility advice: “Observing Users Who Work With Screen Readers”:http://www.redish.net/content/papers/InteractionsPaperAuthorsVer.pdf (PDF) by Theofanos and Redish. I found it very helpful.
There’s alot of focus in the web accessibility world on how to make the web more accessible to the disabled. Sometimes it seems we are trying to please the blind, often forgetting other users with or without disabilities.
Balance is important.
Typical example would be having content first. This also has never made sense to myself (not disabled), though seems like it has been implemented on a large percentage of sites.
I think there is a big problem with the web where people just copy each other. Word gets around and before you know it it’s an expected thing, without much thought going into it. Many of us know that one size does not fit all.
Whilst standards are good, I believe these should perhaps just cover the minimal requirements. We all know that adhering to standards won’t make it work, this is not just for web accessibility, but for many standards and laws in general. What we need are guidelines. Design guidelines, usability guidelines, compatibility guidelines, so forth.
It seems a bit silly to me to implement standards that just don’t work.
It makes sense that research and testing needs to happen to a greater level. One important aspect to understand would be how to disabled users use the web. What settings do they use? As they generally become more experienced what are their expectations? What would they like to see? And how can the web community create a balance?
lets try to do a list of usability guidlines and workarounds here, testing its needed ¿no? lets do some guidlines and test them, many of us here make websites for a living, I know that budget and client espectations are an issue but its better to try and fail that to sit waiting for an answer from heaven.
I have a question on the bold font issue, ¿is there a type letter easy to read for poor sighted people?
If by chance this list of open usability guidlines ever needs a web space to keep growing I can provide a space and some company time to make this project keeps moving.
And sorry for my poor english.
I found that the best way to develop an accessible website is to use a dynamic language (PHP, ASP, etc) that loads different CSS files for both larger and smaller text sizes and also a version that is high contrast (black background, yellow text, etc) If anyone’s interested I’ve set up a beta site for a client that does just that, and the site will be jsut about WAI-AAA certified when I finish debugging.
I have learned that the best way to design a website is to start with a logical layout. Meaning that you lay out the page using XHTML as if the CSS doesnt exist. CSS likes when you have a well structured page because then it knows exactly what to do with it. If you have a logical layout, if the CSS doesn’t work for whatever reason, the page might look spartan but at least you will have a accessible layout. You can also use different CSS files to change the way layout and text is viewed by different browsers. And you can also create a CSS file that allows visitors with handhelds and cell phones to view your pages. But you must remember that web pages will be viewed differently by different browsers and no current browsers support CSS fully. I think that whats important is that we create sensible pages with sensible CSS files and just realize that complete accessibility soley depends upon what you’re visitors are using. Of course, making all these CSS files can create more work then if you just laid your page out with XHTML.
What does all this have to do with visibly impaired visitors you may be asking. Many visitors like different browsers such as IE or opera. Alot like to set their text to different sizes and many others like to use their own style sheets to surf the web. As a professional web designer give yourslef a break by accepting that you do the best you can with the amount of time and budget that you have, and if you truly do the best that you can, then don’t beat yourself up.
Im always looking to make my own website better and im always interested in your comment, questions and concerns. Send me an email at contactbizenez@bizenez.com and dont forget to check out my website at http://www.bizenez.com
Last month I wrote a email to a german group which work for persons with disabilities. I ask following:
– can persons with disabilites create sites by their own
– how do persons with disabilites see a site
– what is important on a site for persons with disabilites
and last, is it possible to create a site on team work?
The answer was great, they tell me, that a team work is possible, but dependent from the level of disabilitie. And the next answer was also great. Persons for disabilites have interest about normal things in the world, but not how a site is make.
After that I get some links to see some examples of sites, who made for and made with persons for disabilites. I see technics with tables, div’s, HTML, XHTML, tabindex and access keys. But all pages are made different. On some sites they use images (sample: house for home), on other they use only the “title” attribute.
I think, all Web Designers can’t make really a perfectly site for persons with disabilities, only in team work with this people. All recommendations from W3C or other experts are only a recommendation, but not a real cook book.
Are you kidding me? But Web designers sure don’t need to be doin’ it. Study design and statistical analysis probably aren’t in your bag of tricks.
However, there are plenty of people out there who _do_ know how to do this stuff, and you’ll find them at any major research university.
I’m seeing a collaborative effort between, say, the School of New Media at NYU and a school of education. A well-designed study could probably get federal and/or foundation funding and assistance from researchers in appropriate disciplines all over the country.
Hell, there are probably studies out there already that just aren’t Web specific, but could at least point in the right direction. Time for a lit search!