Accessites.org
A Comparative: Accessibility and Usability

8 Responses to: “A Comparative: Accessibility and Usability”

1. Rob Mason responds:
   Posted: September 4th, 2007 at 5:49 am →

   A worthy debate Mike. It’s something I tied myself in knots over when explaining it to others. I personally don’t feel you can have one without the other.

2. Mathieu Bonnet responds:
   Posted: September 4th, 2007 at 8:10 am →

   1. You visit a site that has a contact form, but the form relies on the setting of a session cookie to temporarily store values. Users who don’t accept cookies cannot use the form because storage of one of the values is obligatory. As a graceful degradation, the maker of the site has supplied a few contact alternatives to the form.

   - It is a usability issue, if the maker did not warn about it, in a clear manner, both before having the user fill the form, and in case the cookie is not detected when the user sent the form.

   - It is an accessibility issue, if the message about the cookies cannot be understood by some people (beginner, elderies, learning disability, etc.), but have their cookies deactivated for some reason. They will either waste time trying to understand the message, and simply not understand at all, and give up.

   - It is a usability, accessibility and ergonomic issue, if anyone has to use another mean to contact the maker, because:

   —– it takes time (usability, waste time on this kind of matter is not efficient, and ergonomic, because humans generally do not want or can waste time);

   —– it might not always be technically possible (no access to email software or webmail, or you don’t remember your password or do not want to enter it -cybercafe, school, work, etc.-, which is an accessibility issue, because you have to think about what might be available to the user, and an ergonomic issue, because humans go to cybercafes, school, work, etc., where they might not be able to use emails);

   —– the alternative mean might, by themselves, not be usable (e.g., having to use a mailing-list -most notably those who require a full registration), accessible (e.g., a phone, for someone who cannot or have difficulty talking) or ergonomic (e.g., humans might not like or feel like using phones or writing snailmail letters).

   The solution would obviously be not to use cookies. In all cases, to avoid using cookies for guests (except if really needed, of course, like to save a cart on a website selling products), and for forms, to include the session id as an hidden input field.

   2. You encounter a wedding site that uses an image replacement technique on its page headings. The headings’ type-face is a fancy script face that is difficult to read. Enlarging the text doesn’t help because the headings are fixed-size images. You find yourself struggling a bit to better understand those elegant but illegible headings. Yet, screen reader users, text browser users, no-style users, and those without images have no difficulty at all because a good technique was implemented.

   - It is a usability issue, because we cannot easily enlarge the font as needed/required (Opera would do it, IE7 as well -if I remember correctly, because I still didn’t test IE7, although I read the official changelog when it was released-, and there are extensions for Firefox -and there are software and hardware magnifying glasses).

   - It is an ergonomic issue, because typographic rules about clarity for humans, were not taken into account.

   - It is an accessibility issue, because some users might need larger fonts, but might not know what to do to enlarge these pictures (appropriate browser/extension, software/hardware magnifying glass, deactivating stylesheets and then enlarging the text, etc.).

   The solution is to concentrate graphic art on the site and block borders and empty zones (and not abuse it). Text must be normal text (except, possibly, for the name of the site, in some logo). People will not even notice the difference.

   3. You are checking out a web site and you happen to have one of those snazzy mega-monitors with an outrageous resolution. The maker of the site decided on a liquid layout, but hasn’t constrained the width to remain reasonable. As a fully enabled user you are trying read the content, but by God the lines are over 2000 pixels wide and you keep getting lost!

   - It might be a usability issue, if the user do not know how not to use his browser maximized, which should be quite rare, if he brought such a monitor (he will anyway probably find about it, soon).

   Otherwise, although lines too long might sure be a huge accessibility (people having reading problems) and usability and ergonomic issue (too much eye movement, problems tracking lines, tiredness, etc.), I find the solution quite simple, although I sure would limit line size on my websites to the usual 65-75 character per line, using the “em” unit for the container width (so people can enlarge the font, without seeing only a few words per line ), because some beginners sure might not know or think about not using their browser window, maximized (well, my current website do not follow this -I defined alternative stylesheets, but I do not expect anyone to use them, and the container width was defined in pixels, instead of “em’s”.-, but it is an old temporary website, with almost no content, and which I will replace very soon now).

   I also read that some people prefer reading long lines (some dyslexic persons, I think I remember -while most other dyslexic persons (and most other users, as we all know), would prefer shorter lines, if I remember correctly), so limiting the line size, even using “em” units, might not always be a good idea (as far as I’m concerned, I probably will at least define an alternative stylesheet for “free-width content”, but people which are interested will probably not notice, unless I use some information notice about it, for new users, which I will probably do, although it is not that simple for it to be effective).

   4. You’re on a site with a Flash presentation. You have the plugin and have no issues with the presentation’s movement or visibility, but it runs fast and you’re a slow reader. The written content in the presentation actually appears elsewhere on the site, but the connection isn’t obvious so you struggle to read the thing, finding you have to replay it three times before getting the complete message.

   - Accessibility issue, because, as said in the scenario, some people are slow readers.

   - Usability and ergonomic issue, because being forced to read fast, is seldom enjoyable, you might miss information, it might increase your stress, and you might not even want to read this text, but because it is a linear, scripted animation, you are forced to read it completely, without being able to skim through it. Moreover, your attention is generally drawn to fast-moving things (in nature, this often means danger, and abusing it is really bad, both because you might reduce your reflexes, and because it is vicious to try to profit from this kind of natural mechanism -I’m mostly talking about advertising, here, so it’s not really part of the scenario), so you might waste time watching this animation, when you might not even want to have anything to do with this animation (if there is some other content on the page, you might not be able to read it, because your attention is drawn to the animation -and I’m not even talking about people with attention problems).

   The solution is not to use Flash at all, or at least provide a “pause” button, and/or use slower text, and/or permit to skip through the slides.

   This applies to similar technologies, for websites with podcasts or video news/logs (well, Flash is often used for them too), which do not provide any alternative… (or only a short summary), and this is an increasing trend, even on large websites.

   While using audio and video is a good thing (with appropriate subtitles and descriptions), text *must always* be present separately, for *so many* reasons.

   5. You visit a site that is stunning, but uses a rather light shade of gray on a white background making the text difficult to read, yet with all non-visual user agents the text is fine

   - Accessibility issue, because people might not be able to read the text (but might still use a graphical browser).

   - Usability and ergonomic issue, because reading text with low contrast is seldom enjoyable, can be very tiring for the eyes (notably depending on the room luminosity), and might make you waste time, deciphering the words… (and using tricks like selecting the text, might not always offer that a better contrast -well, it depends on the window theme you use, but people might not know about it, or simply might not try to improve this).

   As with the wedding site, the solution is to concentrate graphic art on the site and block borders and empty spaces, and keep the text as simple as possible (with the usual few typographic CSS adjustment).

   6. Now you’re on a site that has several divs used to break up the page (like my first portfolio actually). The site has a fixed width of 760 pixels, and a fixed height of around 550 pixels. It has a center content section and two sidebars, one left, one right. Each sidebar has three sections. All of these sections, due to the fixed height, are styled with the overflow property auto. Thus when the text is enlarged, you find you have a site with no less than seven scroll bars.

   - Accessibility issue, because it makes it hard to enlarge fonts (although Opera and IE7, or Firefox with extensions, should be ok, as said for the first scenario).

   - Usability and ergonomic issue, because it is annoying and makes it harder to concentrate on the content.

   The obvious solution is not using “auto” for overflow, and using “free-height” design (if not a complete liquid design).

   7. You find a fantastic looking site, but all of its content is in large embedded page images. Its got great contrast, and the text is large enough to be easily readable to the vast majority of sighted users. For users that can’t process images, there is a longdesc attribute within the image markup. The attribute’s value is a web address pointing to a text, *.txt, file. There is no physical link to this page, but machines should be able to process the longdesc’s value to access the markup-less text.

   - Accessibility issue, because “longdesc” might not always be supported (although I guess most screen readers and speech synthesizer, do support it), and, in all cases, requires breaking the page into subpages for no serious reason (a serious reason would be, for example, to describe photos, drawings, or graphical charts), so it complexifies the the navigation and makes it harder to skim through the page (well, if there is an “alt” attribute, with some appropriate short description, you should be able to determine if you want to read the full description, or not, but it is still more complex than it should be).

   - Accessibility issue, because some people who still might not be able to read the text, might not know or think about the appropriate browser feature, or hardware/software magnifying glasses.

   - Accessibility, usability and ergonomic issue, because markup is important, both for navigation (possible hierarchy and links, for example), and typography (for emphasis, or variable-width fonts, for example).

   - Usability and ergonomic issue, because it is generally annoying, notably if we want to select some text, but we cannot (and not just to copy it… it might be simply to create some temporary emphasis, when you think some passage is interesting, or to remember where you stop reading, before you answered the phone…).

   8. You use a keyboard, and the site you’re visiting doesn’t provide link focus. You get lost on the page a couple of times as you tab around.

   - Accessibility, because some users require tabbing between the links in a graphical browser (and might, in addition, have reading or vision problems). This also apply, very temporarily, to users who might not be able to use their mouse, for whatever reason (pizza, anyone? ), although this probably would also be a usability and ergonomic issue, due to the temporariness of the problem (that is, the website is just hard to use, in some situations).

   - Usability and ergonomic issue, when some user clicked on a link, then went back on the page, but cannot find where he stopped reading and clicked on the link (notably when the text is not spaced enough, and there is not enough hierarchy, which could be recognized).

   The obvious solution is to adjust the focus style, although we must be careful that the link is always properly readable (notably by making sure borders are not too close to the link text -by adding padding and/or using outlines-, which is not that easy, on all browsers).

   9. You still have your keyboard fired up and you’re on another site that uses the tabindex attribute on all links and form elements. The order, while logical to the site’s maker because of simple familiarity, isn’t natural so again you find yourself lost at times.

   - Very similar to my first point about the link focus problem.

   The solution is not to adjust “tabindex” at all. You should order and markup your source code properly, so that tabbing does not lead to any order confusion.

   The only problem I see with this, is when you want to have a different source code block order (and by block, I mean major blocks, that is the main menu, the possible secondary menu, the possible footer menu, the possible additional sidebar components, like a searchbox, a newsletter registration box, the main content block, etc. -you should never have to change the order of anything else, if your source code and design, are clean), for example, if you want to have your secondary sidebar, below your primary sidebar, in the source code, so people will be able to read it (of course, there would be appropriate skip links), before reading the content, as they might not read it if it is at the end of the source code…

   However, if you modify the source code order for this case (that is, restoring the order seen in a graphical browser), then users using a text browser will be moved from one end of the document, to the other, which is really bad, notably because tab order is really important to them.

   In conclusion, the best solution is not use “tabindex” at all, and the only order change you are allowed to make in your source code, is putting the possible secondary sidebar, below the primary one. In your graphical design, you place the primary sidebar on the left, and the secondary one, on the right (well, maybe the contrary, for right-to-left languages, I don’t know…), with the content between the two. When tabbing, the user will be moved from the header, to the primary sidebar, to the secondary sidebar, and, finally, to the content, which, while it might not be that natural (generally, you read from left to right, so you would expect to be moved, from the primary sidebar on the left, to the content in the middle, and then to the secondary sidebar on the right…), should not be too unintuitive (menus and tools, first, and then the content…).

   Well, there might be some use to “tabindex”, but as far as I am concerned, when I use tabbing, I want to follow the strict order of what I am seeing on the screen, and not skip any element, or even jump from one part of the document, to another, because someone thinks they are not as important as others. Of course, this takes more key press, and it’s a bit annoying, but the solution is not to skip elements (that is, to have to tab between all the other elements using “tabindex”, first), which might, sometimes, be needed (the real solution is better interface standardization, and the possibility to easily skip blocks, sections, etc. -like screen readers and speech synthesizer (and some Firefox extensions, I think I remember) can generally do, because they know it is important-, and quickly go to the element you want to select…).

   Of course, in some browsers (mostly text browsers), you could use your arrow keys, to go strictly, from element to element, without following the “tabindex”, but, not all browsers support it, and people might not know or think about it (or might not even be able to use anything beside tabs, notably if the input device being used, is very limited, for any reason -important motor problem, or basic device).

   10. You have an accented character in your name and when you try to input that letter while filling out a contact form on a site you find yourself suddenly whisked away to an accessibility statement or accesskey details page. The maker of the site added accesskey attributes to selected links and, being thorough, followed one or more of the known standards.

   It is purely a Web browser and system user interface problem, because not enough attention is put into these kind of things (of course, the fact that there is not enough standardization -and it is not just a matter of better defining the “accesskey” attribute, because there are quite a number of differences in handling shortcuts, depending on OS, window manager, device, etc.-, makes it even more difficult for developers).

   The solution is to seriously think about it, once and for all, and remove the “accesskey” attribute, to replace it with proper interface standardization, and the possibility to configure the shortcuts ourselves, in our browser. Of course, as always, there will be compatibility problems for years and years, but not doing anything, only because of this, is always worse.

   This said, currently, it is an accessibility issue, for people with attention and learning problems, and for beginners, because it will completely confuse them, and they might have no idea about what to do, and might not always think about using non-accentuated letters. It is a usability and ergonomic issue, because it is confusing for everyone, even those who might know about access keys and about the problems with some browsers/systems, using the same shortcut, for multiple things.

   Globally, all these scenarios sure involve accessibility, usability, and ergonomic issues, as mostly anything we do, in the current society.

   They sure should be dealt with, together, and probably by the same person (or the same team, as these three fields can involve very specialized knowledge), but everyone (I mean, everyone involved in anything which might be used in any way -not just websites) should know most there is to know about the three fields, for a proper global view, and for the benefit of all. There should of course be specialists, for teaching and checking, but most people should really know about most there is to know (and most people already know quite a lot, but they seldom use this knowledge, because they don’t make the association, because they don’t have the time or budget or motivation, etc. -this is a global problem of today society, among many others).

3. Marc Ashwell » Blog Archive » links for 2007-09-04 responds:
   Posted: September 4th, 2007 at 4:22 pm →

   […] A Comparative: Accessibility and Usability - Accessites.org […]

4. Jermayn Parker responds:
   Posted: September 4th, 2007 at 10:30 pm →

   I just recently went to a Vision Australia accessibility so this is all fresh to me and imo I would say:

   1) dunno…
   2) accessibility coz it does not make it viable for some viewers.
   3) a coding issue and so i would say usability as its not usable.
   4) accessibility as it does not factor in the slower readers and possible people with disabilities.
   5) both???
   6) Usability
   7) neither… bad coding
   8) accessibility
   9) accessibility
   10) not 100% sure, maybe usability

   btw Mike I think you have made your point and I would agree with you that a lot of it ties together but then again so all web stuff should. All should work together for the same outcome and if not it will not work as it should (bit like ingredients for a cake).

5. Phil Smears responds:
   Posted: September 6th, 2007 at 1:20 am →

   I don’t feel tied up in knots by it but maybe I’m oversimplifying.

   If you take the stance that accessibility issues are usability issues for disabled users then all issues above are usability issues. When they disproportionately impact disabled users they also become accessibility issues.

6. Mike Cherim responds:
   Posted: September 10th, 2007 at 6:57 pm →

   It was my intention to provide my views on the items above after the post was read. Response wasn’t as good as I had hoped, but here goes:

   1) Cookies for a contact form: I’m sort of torn on this one but I would think it is a “both” because there should be a way to use a contact form without cookies being enabled. Cookies should be a progressive enhancement resulting in a convenience and nothing more.

   2) Illegible image text: Both. If an image replacement technique is used one must be sure to make sure the image text is readable. It’s a usability on one hand, while accessible to some, it’s still not accessible to others.

   3) Too wide text I think is a both issue. Accessibility for some users, usability for others, depending on their needs.

   4) Too fast Flash. The accessibility side of Flash should be covered already, so this seems to me to be a usability issue.

   5) Too light text: Both.

   6) Multiple scroll bars: Usability mostly.

   7) Image content: Accessibility. Even though the letter of the law is covered with the long description, the text file has no semantics, and there’s no guarantee that those who don’t use long descriptions, your average user, will get the goods anyway.

   8) No focus: Both. The lines are blurred with no focus

   9) Tabindex mess: I think I give this one a usability issue with some accessibility sprinkled on top.

   10) Accesskeys disaster: Both I think, but mostly usability (accessibility at the expense of usability… hmm).

   It seems as if it’s very difficult to address or miss one with addressing or missing the other.

7. Daniel Power responds:
   Posted: September 11th, 2007 at 12:30 am →

   If you take the stance that accessibility issues are usability issues for disabled users then all issues above are usability issues. When they disproportionately impact disabled users they also become accessibility issues.

   Exactly how I see it, well said.

8. Stevie D responds:
   Posted: September 11th, 2007 at 3:50 pm →

   1. You visit a site that has a contact form, but the form relies on the setting of a session cookie to temporarily store values.

   Accessibility issue - the user’s computer may or may not enable them to access the form. It’s not that the page is difficult to use, but it may be impossible (ie inaccessible). Some credit for giving an alternative contact method though.

   2. You encounter a wedding site that uses an image replacement technique on its page headings. The headings’ type-face is a fancy script face that is difficult to read.

   Given that many user-agents do not allow scaling of images, I would say that this is an accessibility problem. Although it’s trivially easy for a competent Opera user to solve, and moderately easy for a competent Firefox user to solve (assuming it’s a well-designed CSS image replacement) - by turning off images/stylesheets, the majority of users won’t have that option. Even those with IE7 who can scale the image, or who try that solution in Opera/Firefox, might find that the image is still is illegible even at larger sizes.

   One author-side solution is to put a title attribute on any text where you use an image replacement, so that the text will also be rendered as a tooltip on mouseover.

   3. You are checking out a web site and you happen to have one of those snazzy mega-monitors with an outrageous resolution.

   This is a user-education issue, caused by sloppy design techniques and/or IE6. If the user doesn’t find a 2000px wide viewport easy to work with, he should reduce the size of the viewport - that’s easy enough to do. Yes, it would help if the author had given a max-width:50em; and, ideally, a Javascript workaround for IE6, but this is one area where the users can solve the problem for themselves, so don’t need the author to.

   4.You’re on a site with a Flash presentation. You have the plugin and have no issues with the presentation’s movement or visibility, but it runs fast and you’re a slow reader.

   As a text alternative to the Flash has been provided, accessibility requirements have been met. If the issue is that the user is having difficulty finding the section of the site he needs, that is a usability issue.

   5. You visit a site that is stunning, but uses a rather light shade of gray on a white background making the text difficult to read, yet with all non-visual user agents the text is fine.

   Until such time as the majority of users are able to turn styles/colours on and off easily and quickly, I would say this is an accessibility issue. Matters of colour contrast and brightness differential have traditionally come under accessibility, and I don’t see any reason for this not to apply here. Accessibility doesn’t only apply to people not using a graphical browser and a mouse, it applies to people with any disability or condition that means they can’t access a website’s content. Here, the author hasn’t provided a sufficiently legible colour scheme.

   It would be great if we could persuade every web user to download Opera, or if Microsoft would add a “turn off site styles” button to IE (including a patch for all existing users), so that we could leave this as a user-side solution - but until that happens, authors have to make sure that the colour scheme they use is likely to be accessible to the vast majority of users.

   6. The site has a fixed width of 760 pixels, and a fixed height of around 550 pixels. It has a center content section and two sidebars, one left, one right. Each sidebar has three sections. All of these sections, due to the fixed height, are styled with the overflow property auto.

   This is an issue of bad design, which may impact on usability, but reaches way beyond that. The content is all there and can be resized, so it isn’t an accessibility issue. The problem here is that the designer is still stuck in “print” mode…

   7. You find a fantastic looking site, but all of its content is in large embedded page images. For users that can’t process images, there is a longdesc attribute within the image markup. The attribute’s value is a web address pointing to a text, *.txt, file.

   Definitely an accessibility issue, and a serious one at that. Regardless of the perceived clarity, text embedded in images can’t be resized, highlighted, copied or manipulated in any way, which will stop people interacting with it in the way they wish to. Relying on longdesc is not satisfactory as most browsers provide no obvious mechanism for accessing it. Yes, they should, but they don’t, and we as designers must allow for that. Having the alternative content in plain text is not satisfactory, as there is no semantic content so assistive technologies will not be able to intelligibly render the page.

   8. You use a keyboard, and the site you’re visiting doesn’t provide link focus.

   There is no barrier to accessing the links, given that all browsers that I’m aware of do indicate where the current focus in. The problem here is that it is often difficult to spot the default browser focus, which makes the page difficult to use - definitely a usability issue.

   9. You still have your keyboard fired up and you’re on another site that uses the tabindex attribute on all links and form elements.

   Again, it’s a usability problem, but one that has been caused by an author trying too hard to be accessible without knowing enough about it. I won’t knock authors who use tabindex because they think it is making their site more accessible.

   The only time it becomes an accessibility issue is where the tabindexing has gone wrong and the user can’t tab to all links and form elements.

   You have an accented character in your name and when you try to input that letter while filling out a contact form on a site you find yourself suddenly whisked away to an accessibility statement or accesskey details page.

   I think this is a usability issue - it certainly isn’t an accessibility one. And it shouldn’t happen. The (UK) standard set of accesskeys uses the digits 0-9 and the letter S, so isn’t going to conflict with any accented characters. It might conflict with other browser or computer commands though. That’s why, for the vast majority of sites, accesskeys are more of a hindrance than a help. Again, I won’t complain about an author who uses accesskeys out of good intentions, but in general it is likely to cause usability issues for people.

   Yes, there is a lot of overlap between accessibility and usability. I’m sure when there are a few more comments there will be some vehement disagreement amongst the contributors. What we shouldn’t lose sight of is that they are both important - a website that is accessible but not usable, or vice versa, is not a good website. Rather than arguing about the distinction and boundary between them (yes, as I have just expended a considerable amount of time doing), we should be looking to tie them together, presenting them as a united front for better website design.

Sorry. Comments are closed.