Working with Others: Accessibility and User Research

by Maurizio Boscarol

45 Reader Comments

Back to the Article
  1. 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.
  2. 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.
  3. Paper (in PDF form) of observation of users working with screen readers, with recommendations.:

    Copy & paste the code below to embed this comment.
  4. I have fairly recently attended a presentation done by “test partners” ( 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.
  5. Woops… sorry, can someone clean up my previous post, the preview function did not work.

    Copy & paste the code below to embed this comment.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. Nice discussion. I hope some clarification (other than “what I already said about text size”: 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.
  12. 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.
  13. 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.

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

    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.

    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.

    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.
  15. 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”: 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.

    about skipping link: Looking into wcag 1.0 techniques you will “find this”: , 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:

    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.
  16. 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.
  17. 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.
  18. 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.

    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.

    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.
  19. 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”: (PDF) by Theofanos and Redish. I found it very helpful.

    Copy & paste the code below to embed this comment.
  20. 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.
  21. 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.
  22. 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.
  23. 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 and dont forget to check out my website at

    Copy & paste the code below to embed this comment.
  24. 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.
  25. 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.