Working with Others: Accessibility and User Research

by Maurizio Boscarol

45 Reader Comments

Back to the Article
  1. 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?
    Copy & paste the code below to embed this comment.
  2. 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.
    Copy & paste the code below to embed this comment.
  3. 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.
    Copy & paste the code below to embed this comment.
  4. In fact, expectations would be a better word than convention.
    Copy & paste the code below to embed this comment.
  5. 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.
    Copy & paste the code below to embed this comment.
  6. 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
    Copy & paste the code below to embed this comment.
  7. 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…
    Copy & paste the code below to embed this comment.
  8. 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.
    Copy & paste the code below to embed this comment.
  9. 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.
    Copy & paste the code below to embed this comment.
  10. 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
    Copy & paste the code below to embed this comment.
  11. 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! :-(
    Copy & paste the code below to embed this comment.
  12. 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.
    Copy & paste the code below to embed this comment.
  13. 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
    Copy & paste the code below to embed this comment.
  14. I guess reloading doesn’t help when comments move on to the next page. Didn’t mean to repeat the authors comment.
    Copy & paste the code below to embed this comment.
  15. 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.
    Copy & paste the code below to embed this comment.
  16. 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.
    Copy & paste the code below to embed this comment.
  17. 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 <link rel=”...”> elements, eg home/next etc? If so, including them would be a good solution to the problem.
    Copy & paste the code below to embed this comment.
  18. 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.
    Copy & paste the code below to embed this comment.
  19. 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.
    Copy & paste the code below to embed this comment.
  20. 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</a> (slide 37).
    Copy & paste the code below to embed this comment.
  21. 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.
    Copy & paste the code below to embed this comment.
  22. 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.
    Copy & paste the code below to embed this comment.
  23. Paper (in PDF form) of observation of users working with screen readers, with recommendations.: http://www.redish.net/content/papers/InteractionsPaperAuthorsVer.pdf
    Copy & paste the code below to embed this comment.
  24. 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 <noscript> as it thinks that it can handle the JS.
    - It is very difficult to get JavaScript to alter the content and still inform the user it has happened (e.g. image rollover to show a description). - 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 <ol>)
    - 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 <h2> should help avoid confusion.
    - Sub Navigation should not use nested <ul>‘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 <select> with onchange for a nav… most users do not know how to expand the field to avoid the event triggering. - Every field needs to have a label.
    - Do not follow WAI guideline “10.4” (include place-holding characters in fields) as the user will rarely realise the need to delete the text.
    - Additional information for a field (possibly in a ) should appear before the field and refer to the field “below”.
    - A user can move into “forms mode” which only reads the label and field (no other content in the form).
    - Each label is prefixed with the <legend> value.
    - Use an asterisk to mark mandatory fields (not background images).
    - When the form is submitted for server side validation, it helps to use the <title> to tell the user immediately that something has gone wrong.
    - Using a <ul> to list form errors is easy to identify, although the fields with an error should also be marked with something more than red text.
    - Avoid the use of JavaScript text injection validation. Usually very difficult to get it to inform the user why the form did not submit due to an error.
    - Best form of JavaScript validation uses an alert() box as it steals screen reader focus, although this is not good for users of screen magnification software. - Tables need a summary / caption if the meaning is not well defined.
    - Each table should use the scope (th) OR headings (td) attributes to help identify each table cell.
    - Never use tables for presentation (very distracting with the screen reader announcing the begging of a table with row and col count).
    Copy & paste the code below to embed this comment.
  25. Woops… sorry, can someone clean up my previous post, the preview function did not work.
    Copy & paste the code below to embed this comment.
  26. 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?
    Copy & paste the code below to embed this comment.
  27. 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.
    Copy & paste the code below to embed this comment.
  28. 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.
    Copy & paste the code below to embed this comment.
  29. 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.
    Copy & paste the code below to embed this comment.
  30. 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.
    Copy & paste the code below to embed this comment.
  31. 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!
    Copy & paste the code below to embed this comment.
  32. 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.
    Copy & paste the code below to embed this comment.
  33. 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?
    Copy & paste the code below to embed this comment.
  34. 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.
    Copy & paste the code below to embed this comment.
  35. 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!
    Copy & paste the code below to embed this comment.
  36. 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.
    Copy & paste the code below to embed this comment.
  37. 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 :)
    Copy & paste the code below to embed this comment.
  38. 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!
    Copy & paste the code below to embed this comment.
  39. 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.
    Copy & paste the code below to embed this comment.
  40. 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?
    Copy & paste the code below to embed this comment.
  41. 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.
    Copy & paste the code below to embed this comment.
  42. 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.
    Copy & paste the code below to embed this comment.
  43. 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 www.bizenez.com
    Copy & paste the code below to embed this comment.
  44. 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.
    Copy & paste the code below to embed this comment.
  45. 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!
    Copy & paste the code below to embed this comment.