Web standards vs. Accessibility

Lately I’ve seen some arguments that valid code and semantic markup – web standards – aren’t essential for making a website accessible to screen readers. I’m not going to argue against that. It is true to some extent. Screen readers need to eat the same junk food as visual browsers, so they also need to compensate for invalid markup.

Furthermore, screen readers don’t currently make proper use of all that tasty semantic markup we offer them. Because of this, some argue that using semantic and structured markup is more or less pointless from an accessibility perspective. If you’re a regular visitor to this site, you already know that I strongly disagree.

Even if using web standards did not benefit screen readers at all, that wouldn’t change anything. First of all, accessibility covers many other disabilities than blindness – something that is often forgotten. But for the sake of this argument, let’s focus on screen readers.

What if we were to completely remove screen readers from the equation? Let’s just assume that screen readers suddenly parse tag soup just as well as the Master of broken code, Internet Explorer, and have no problems making sense of even the most convoluted mess of nested tables, presentational markup and spacer GIFs. What then? Will there be no need to care about web standards and best practices anymore? Did we lose and the Frontpage jockeys win? Absolutely not.

Using valid, semantic, and well-structured markup combined with accessibility best practices makes for a better experience for many more than just screen reader users. In fact, it will give every web user a better experience because:

  • people that use other browsers than Internet Explorer and other operating systems than Windows will be able to use the site
  • user agents that have CSS disabled or do not support it will get unstyled but well-structured and fully usable (X)HTML
  • user agents that do not support JavaScript will still be able to use the site
  • the site will be faster thanks to reduced file sizes compared to table-tag soup
  • the site will be usable in mobile and handheld devices
  • accessibly marked up forms enhance usability for everybody
  • teenagers who like to lean back in their chairs while browsing the web as well as senior citizens will be able to increase font size without making text unreadable

I could go on. Accessibility is not just about screen readers or blind people. Making a site specifically tailored to screen readers is not accessibility – it is building a blind-only site that does not take into account the wide range of disabilities that affect the way people use the web or the many different browsing devices that are in use.

To me, true accessibility is building one site that works for everybody, disabled or not, and whatever user agent or operating system they prefer. And that is the web I want to build and use.

Update: Edited to clarify a few things pointed out by Isofarro in comment #22.

Posted on June 16, 2005 in Accessibility, Web Standards

Comments

  1. June 16, 2005 by Gary Turner

    Ha! Forget the user. Well structured, semantic markup is easier to prototype, debug, and maintain. I cannot imagine even trying to build a page in the old table and tag soup manner.

    cheers,

    gary

  2. ‘Forget the blind’ was the title of an essay on a French-Canadian blog. Well structured markup is also good for people who use the keyboard, and all the other reasons we’ve discussed in the past.

  3. I completely agree - it is the web I want to build and use too! One of the strengths of good semantic markup is that it does make sites useable for everybody - it is one of the aspects I admire most about it! In the past, before web standards were being followed so closely, and HTML was the standard, it seemed that accessibility best practices weren’t being met at all…and now, with improved markup, there is no excuse for not doing it. That is MUCH better in my opinion! As you’ve (nicely) outlined already: the reasons for continuing to use web standards, and the true meaning of ‘Accessibility’, remain as important issues for the web and should be promoted properly at every opportunity…. # flapping the web standards flag again! #

  4. Exactly why I find it extremely ‘icky’ to throw the word disability into the same room as accessibility. Even though it does hold some thruth, it’s clear we shouldn’t be taking and using it for formulate certain project goals, e.g. making the site accessible for disabled users. Instead, we shake our magic web standards wand, write semantic code, unontrusive Javascript, and that itself should be a project goal, so it can properly function as a starting point for accessibility.

    Unfortunately, if I remember correct, the intro of the WAI awefully a bit too much around disabled users, in my opinion.

    How much should disability (real disability, even though you could call using MSIE/Mac a disability as well ;-) weigh in the accessibility debate?

    Continue writing these articles. You’re filling up my bookmarks lovely and always function as a great reference in any reports people want me to write :-)

  5. Writing propper and semantically markup is a good basis for accessibility. Only starting from that fundament and adding other accessibilty relevant features/parts to the markup enables the highest level of accessibility as possible. Of course not only for impaired people. In my opinion too, web standards and accessibility are symbiotic.

  6. June 16, 2005 by ghola

    It must be hell having all these people agree so strongly, on your own blog!

    Of course I do fully agree like anyone here, but I also wonder who professed the arguments you are debunking. Are they major players in any field?

  7. June 16, 2005 by Fredrik

    I agree as well. But how come everyone making these examples go to extremes when doing the comparison?

    For instance, sometimes it’s a matter of a CMS or one of the recent discussions over at http://www.robertnyman.com about .NET which spits out non-valid HTML. This can be fixed but occassionally you might get an invalid attribute in there.

    If you call a customer and say: “Hey, know what? We’re going to have to push the deadline until next week or so, we just discovered that the .NET framework outputs an attribute that it needs to work, but it doesn’t validate according to w3c recommendations”.

    Another thing is that writing proper, semantic XHTML isn’t hard at all really. The main problem is displaying it in a visual manner that allows cross-browser accessability. I am all for w3 recommendations on this, percentages for layout, Em (or other relative) for font-sizes, etc, etc. But it’s dang hard to implement for every browser out there.

    The real issue lies with accessible CSS. It’s when we reach to the point where content is to be presented visually that people start using javascript sniffers and lately even server-side sniffers. Opera 8 seems to have made these go haywire. Until recently a major site tossed me a server-side error when visiting it with Opera.

    In this case, serving valid CSS to the correct browser goes to far IMHO. Even if a comment hack or two doesn’t validate, don’t break what works. In this case accessability wins over webstandards…

  8. Absolutely agreed.

    When it comes to this funky screenreader problem, a rigorous course needs to be encouraged - of course meaning that we absolutely need to continue to stick up for Web standards (what a question). Sooner or later screenreader vendors will accomodate, and the Good will win one day.

  9. Here, here!

    This idea of web standards being incidental-at-best vis a vis accessibility was beginning to get into dangerous territory. The possibility of non-techie decision makers catching wind of that sentimental and filing it away as “web standards don’t do anything” wouldn’t be good for anyone.

  10. June 16, 2005 by Roger Johansson (Author comment)

    Jeroen: Yeah, that article focuses too much on disabilities in my opinion.

    Obviously making the web usable for people with disabilities is important, but we need to talk more about the other aspects of it. That’s why I wrote this post.

    ghola: I can’t point to any single reference. It’s more a matter of reading between the lines of several articles and blog posts I’ve read lately, as well as some of the discussions that were brought up at @media.

    Fredrik: Yes well that is something you learn how to fix, implement it once, and then it’s just a few minutes’ work of fixing it for the next project. Unless you insist on using Visual Studio’s built-in controls, of course. But I’ve found that there are extremely few .Net developers that care at all about web standards. They just eat whatever crap Microsoft feeds them without even thinking about how clueless it makes them look.

  11. the site will be usable in mobile and handheld devices

    People never emphasize this point enough. I know I didn’t, until I tried to check my email on my phone only to find that the webmail my host offers is frame based and offers no “noframe” alternative. Very frustrating.

  12. Yay, I lean back with my laptop in my knee, therefore I’m a teenager! :-)

    You knowI agree, so no point screaming it again and again.

    When it comes to your experience of .NET developers, I agree. They’re usually so MS-blind it makes me sad…

  13. June 17, 2005 by Kalle Wibeck

    This is an important question to discus, what is what?

    “Accessibility” has been taken for “building-for-disabled-visitors” so many times that it almost has become that, of course Mr WCAG and Mrs Section 508 plays a big role in this since they are the main reason governments has put accessibilty on the agenda.

    But what ever happend to the term device independency? Doesn’t the term itself clearify what we normally talk about when we shout for accessibility?

    In Sweden this is even more confusing since the Swedish word for accessibility “tillgänglighet” also might appear to describe a systems availabilty or up-time 24/7-ish :(

    // : ) Kalle

  14. June 17, 2005 by Kalle Wibeck
  15. I spent the last year learning web design from scratch using only XHTML/CSS & working hard on accessibility etc. My nightmare has now arrived in the form of producing html email. To get compatibility and reliability I’ve had to go back to using tables etc and what a pain in the backside it is. I know, I know, use css same for the email too but they do fail miserably in hotmail etc if you do.

  16. June 17, 2005 by Roger Lancefield

    Accessibility is a cool goal, both insofar as it refers to standards and interoperability, and insofar as it refers to enabling people with disabilities to access online information. It’s hard to disagree that online information provided by central and local government, governmental organisations, etc. should as a matter of course be made accessible to the widest possible audience.

    However, as for those individuals, companies and organisations who don’t/aren’t capable (for whatever reason) of producing “standards compliant” code, I strongly disagree that they should somehow be coerced into doing so. Encouraged yes, coerced no. Similarly, I disagree that this should be a matter for legislation and I find it highly unpalatable that those who don’t or can’t produce standards-compliant markup should be regarded as somehow ignorant or degenerate. Some thoughts around the issue:

    • Should street advertising billboards be forced to be “accessible”?

    • Should all cars be forced to be “accessible”?

    • Should a person who doesn’t understand grammar and who can’t spell, or a dyslexic person, be barred from publishing in print on the grounds that they don’t know the “correct” way to write?

    • How many “types” of disability are catered for by “Web standards”, 5%? 20%, more? Which of the possible aids to disability that can be incorporated into Web standards should be a matter for legislation, and which can be exempt?

    • If certain types of disability could be catered for by say, tens of thousands of lines of complex code which could then be used by special “communication devices” to help the sufferer of that disability to comprehend the data on a Web page, should all Web publishers be legally (or even technically) obliged to create such code (imagine a situation where such code costs more to produce than an average, brochure-ware Web site for example)? If not, where should the border or the cut-off point lie from a moral or regulatory point of view?

    • Should (for example) a visual artist who wants to push the design envelope on the Web be forced to do so in a way that meets W3C or national-government imposed guidelines?

    If even the last answer is “yes”, then so much for spontaneity, so much for creativity, so much for the right to be ignorant. If someone creates crap code that can’t be indexed, so what? They’ll soon learn if they want to spread their message widely. If they don’t, that’s their concern and what business is it of legal bodies or anyone else to interfere? Let them wallow in their own primordial tag-soup.

    Why are Europeans, and I’m one of those, so ready to resort to regulation and legislation to solve perceived problems (and we seem to be perceiving them with increasing frequency)? In the end, none of us will be able to move without consulting a rule book. (I’ve acknowledged that public services and data should be accessible to the widest possible audience).

    Finally, I hope that all those Web builders who have recently developed a zealous solicitude for and empathy with Web users with disabilities are also promoting the concerns of the disabled equally in all other areas of life.

    (Apologies for the long post.)

  17. June 17, 2005 by Roger Johansson (Author comment)

    Roger: Long comments are fine, especially thoughtful ones like yours.

    Why are Europeans, and I’m one of those, so ready to resort to regulation and legislation to solve perceived problems (and we seem to be perceiving them with increasing frequency)?

    Because we live in a society where being inconsiderate of others is the norm? Because without heavy pressure most people will just continue to act egoistically and not give a damn about the next person?

    Look, I agree that legislation is not the ideal solution. But I’m not convinced that the hordes of ignorant web “designers” that dominate the industry will suddenly become interested in best practices unless they are forced to.

  18. A site built using web standards does not automatically result in an accessible one. I have been hearing claims like this with increasing frequency and it is just wrong.

    It is possible to have vaild code, css, pass WACG priority one, and still produce a web site with significant barriers for users.

    Accessibility is a highly specialized usability concern, so paying attention to it generally does improve usability for everybody.

    If you can consider blind and low vision users, users with impaired motor skills, and users with cognitative disabilities, then you will produce a reasonably accessible site.

  19. June 17, 2005 by Roger Johansson (Author comment)

    Terrence: Absolutely. I hope you don’t think I’m claiming that using web standards automatically results in an accessible site.

  20. Not at all Roger… I realise you are not making that claim, but I have heard it elsewhere in similiar discussions about web standards and accessibility.

  21. Roger Lancefield’s comparisons to cars and so on are off-topic given that cars are not electronic media formats that can carry accessibility features.

  22. I could go on. Accessibility is not just about screen readers or blind people.

    Quite correct. Accessibility is about removing barriers from a website for all disabled people, not just blind people.

    Accessibility isn’t about screen readers either. Its about people first. The technology is incidental - when that technology cannot make something accessible to a disabled person.

    Making a site specifically tailored to screen readers is not accessibility – it is building a blind-only site.

    Please don’t fall for the myth that accessibility is only about blind people. Its about deaf people, about cognitively impaired people, about motor-impaired people, its about vision impaired people too. But its also not about people who’ve chosen to use Lynx.

    Accessibility is about removing barriers that make it difficult or impossible for people with disabilities to access a site’s content.

    True accessibility is building one site that works for everybody, whatever user agent or operating system they prefer.

    Accessibility isn’t about software choice. The only time software becomes the focus of accessibility is when software alone cannot make content accessible to a disabled visitor.

    And that is the web I want to build and use.

    Its fine and great that this is what you want from the Web - I agree, this is what I also want. But to redefine accessibility as “that which you want” isn’t right. It takes the focus away from the real intent of web accessibility, removing barriers for disabled users.

    Web standards is more closely identified with catering for software choice. Not web accessibility.

    Web accessibility based on web standards is an ideal solution, but it still doesn’t change what web accessibility is primarily about.

    I’m looking at references and definitions of web accessibility now. Almost all of them point to web accessibility as catering for people with disabilities, and a large chunk of them point to the fact that making a website accessible has the side-effect of making content accessible to all people disabled or not. This is a side-effect, not the main point of accessibility.

    This side-effect is great, it gives you what you want and gives me what I want out of the Web, but its not the primary objective.

  23. June 18, 2005 by Roger Johansson (Author comment)

    Isofarro:

    Please don’t fall for the myth that accessibility is only about blind people. Its about deaf people, about cognitively impaired people, about motor-impaired people, its about vision impaired people too.

    Yes, I suppose I should have made that clear in my post. And no, I haven’t fallen for that myth. Many others have. That is one of my reasons for writing this.

    Accessibility isn’t about software choice.

    What if that was reformulated to say “whatever user agent or operating system they prefer or are forced to use in order to access the web”?

    But to redefine accessibility as “that which you want” isn’t right.

    That was not my intention.

    Almost all of them point to web accessibility as catering for people with disabilities, and a large chunk of them point to the fact that making a website accessible has the side-effect of making content accessible to all people disabled or not.

    Yes, and the side-effect is what I am emphasising here, that is correct. My point is that if you’re only focusing on catering to people with disabilities (and in this case screen reader users specifically) it’s quite possible to build sites that are accessible to those groups but not to Mac users or Linux users or users of handheld devices.

    To me, “accessible to all” means just that.

    Thanks for pointing out the flaws in my post. I believe we are fighting on the same side here.

  24. My point is that if you’re only focusing on catering to people with disabilities (and in this case screen reader users specifically) it’s quite possible to build sites that are accessible to those groups but not to Mac users or Linux users or users of handheld devices.

    Spot on. I think its the role of standards such as HTML and CSS to provide the bridge toward cross-platform and cross-browser “accessibility”.

    I believe we are fighting on the same side here.

    Yes. I’m just paranoid people forget that web accessibility is about people. :-)

  25. Roger:

    You wrote

    Let’s just assume that screen readers suddenly parse tag soup just as well as the Master of broken code, Internet Explorer, and have no problems making sense of even the most convoluted mess of nested tables, presentational markup and spacer GIFs.

    Isn’t JAWS just a layer on top of IE that “simply reads” what IE is fed? I know there are other screenreaders but JAWS is the most popular.

  26. June 20, 2005 by Roger Johansson (Author comment)

    Jules: Yes, JAWS does pretty much that as far as I understand it. It still benefits from valid markup though: Influence of valid code on screen readers. Also, JAWS being the most widely used screen reader does not mean it’s the only one or the only one worth caring about.

  27. I guess my comment was a bit brief. You stated and I quote “Lets just assume that screen readers suddenly parse tag soup…”, my intended point was a question as to whether or not screen reader’s parse tags (soup or otherwise). In the link you pointed me to, it states that:

    [Product 1] does tend to behave better with valid code because the browser behaves better with valid code.

    which seems to place the emphasis on the browser, rather than on the screen reader. If the code is bad, then the browser renders it improperly and the screen reader has no choice but to try to deal with the browser’s rendering of the code but in Joe’s comments, he does not say that [Product 1] (his term) parses the code.

    I suspect that [Product 1] is JAWS and later, [Product 2] might be HPR (IBM Home Page Reader). In the case of HPR, which is both a visual and speech browser, one could possibly argue that this “screen reader” is parsing the tags but, without seeing the inner workings of the browser, the rendering engine may be separate from the screen reading engine and therefore the screen reading engine does not parse the code but depends on the parsing engine to do that.

    Maybe, I am being too picky but you “talk” as if the screen reader is doing the parsing whereas, in the case of JAWS, it is not doing the parsing and in the case of HPR, it is not clear.

    In my opinion, it would be better to have an independent screen reader application that is both a parser and screen reader which means that it would (likely) have a user-agent string and could be detected and managed differently than a visual browser.

  28. June 20, 2005 by Roger Johansson (Author comment)

    Jules: It’s hard to tell exactly what screen readers do. I don’t know for sure. Maybe someone who has more insight into the inner workings of screen reader software can speak up?

    The point I was trying to make about tag soup parsing is that even if screen readers could make perfect sense of completely inaccessible old skool “HTML” the way a visual browser can fudge and try to guess what the author meant, it still makes a lot of sense to use web standards and accessibility best practices.

  29. Jules, you are correct. JAWS has no web browsing capabilities. It works transparently with Windows. For web pages it relies on Internet Explorer to do the browsing and then hooks in to the IE DOM to output semantic details.

    Something I find interesting is that JAWS (and many other screen readers) use very little of the semantic markup and none of the aural CSS properties. They mostly deal with headings, lists and tables. An interesting example is the del element which content is output as plain text.

    Being the owner of a often misunderstood domain name I want to make it clear that I fully recommend that you use the W3C recommendations (there really is no other way). But, when too much money is spent wiggling with miniscule semantic details I will recommend that you use that money for something else. At least until screen readers get better (at which time your web site will have changed).

    Working with content gives a lot of “bang for the buck” when it comes to increasing accessibility.

  30. June 23, 2005 by Roger Johansson (Author comment)

    Pete: Agreed, the content itself often needs a lot of work. And spending too much time on semantic details in a commercial project is not a good idea. In our personal projects I think it is a good thing to spend some time thinking about the details though. That way we learn and can apply the ideas to commercial projects without spending extra time.

    And even if screen readers and other assistive technology do not yet make full use of all semantic markup, it does help the fundamental structure of a document.

  31. Article from w3c:

    Business Benefits of Accessible Web Design

    This document is one of several resources created to assist the preparation of a business case for the implementation of Web accessibility. It describes the many business, technical and other benefits to the organization above and beyond the straightforward benefits to people with disabilities…

    A essentinal read on this subject!

  32. To me, true accessibility is building one site that works for everybody, disabled or not, and whatever user agent or operating system they prefer.

    Excellent point! This is my spontaneous understanding of web accessibility.

    I was surprised to see W3C’s definition -

    ‘Accessible’ means to a wide range of people with disabilities, including blindness and low vision, deafness ..

    • which focus on disabilities.


    Does anyone have some references to more general definitions of web accessibility, such as the one Roger Johansson propose?

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.