Why accessibility?

Seems like a pretty easy question to answer, doesn't it? Well, it isn't. If you look further than the obvious standpoint, that of course one wants every web site to be accessible and usable by everyone. From a perspective based on respecting and catering to people with different needs, accessibility is a given. However, let me give you some background first by pointing you to two good articles Roger has written:
Accessibility myths and misconceptions
A good summary of building accessible web sites.
Accessibility charlatans
About people jumping the bandwagon stating that they create accessible web sites to get PR and make money, and then ignorant journalists that don't do proper fact-checking support their claims.
With that as our canvas, enter the business factor. Sure, WAI is the hype word for the moment for IT sales men, but I'm sorry to say this: I still haven't had the opportunity to work in a project that offers an accessible web site, or even a project that has had that set as a goal. For instance, take the project I work in right now: It's a web site based on a Microsoft .NET-based CMS product from one company, with the addition of extensions from yet another company. My problems:
  • To start, we all know that Microsoft .NET generates code that can't be validated as strict XHTML or HTML.
  • The CMS product generates some invalid code on top of .NET's plus the fact that it has a WYSIWYG tool based on Microsoft's contenteditable property, which, to say the least, generates terrible code.
  • To top it off, the extensions mentioned above use span tags as the ultimate block level element, encompassing everything (span tags are inline elements, you morons).
There's too little time and money (as always) in the project, so there simply isn't any window of opportunity or incentive for any system developer to fix the .NET errors. And even if that had been taken care of, we would still have the WYSIWYG and extension problems. So, with that in mind, accessibility isn't even on the agenda. And we're talking about a web site that has roughly 60 000 - 70 000 visitors per day! And, from my experience, this is not an uncommon situation at all. Generally, when you present the accessibility factor to a company, they want it "in the package", but they're not ready to pay anything more for it nor allow for any extra testing. Most companies (and visitors that don't need the accessibility enhancements) are happy if the web site in question displays somewhat correctly. They don't give a damn if it follows web standards, uses correct semantics or is accessible to people with other needs. The companies normally seem to think that the percentage of visitors they lose in not being accessible doesn't make up for the time and testing it takes to go that extra mile (no notice taken to the bad will this will create, however). A very current example: Jens Wedin works for a company whose web site just was elected the best government web site in Sweden. And, as he states:

Take note that the site do not follow web standards, is using frames, do not validate, have a lot of accessibility problems.

I have no doubt that Jens will do his best to push things in the right direction in the future, he seems like a knowledgeable person, but the fact still stands that its current state didn't keep it from getting first place. Another example that seems to come up is Google. Do a search for Robert Nyman, and it returns a page with 437(!) warnings/errors (Ironically, a MSN search, of all web sites, returns a valid XHTML Strict page, although not sent with the application/xhtml+xml doctype, but that's a discussion for another day). This gives people the argument that:

Well, Google seem to do pretty good. And if they don't care about web standards or accessibility, why should we?

I don't really know how to argue with that. Even if every web interface developer in the whole world would know how to create accessible web sites, we still need to convince businesses, customers and decision makers to take it into consideration, to sell the idea of accessibility to the ones that ultimately make the call! How do we do that?

 

Related posts:

Posted in Developing |

70 Comments

  • As Ian Lloyd said, "Embarrassment is a powerful tool"

    Meaning, show the executives their own website using Homepage Reader, and they'll be confronted with the painful reality. That embarrassment can convince many people.

    Also, Google may still be able to read a site, but that doesn't mean that google couldn't read the site better. Right now, Google checks 3 things, mainly:

    – other sites linking to you

    – URI structure

    – content

    If google finds a tag soup content, all points you can score for content will be lost. It may not matter as much as other sites linking to you, but it does matter.

    Additionally, adding accessibility and usability to a site usually means also changing the URI structure. After all, accessible and usable URI structures are simply much better for everyone (google cares about this a great deal) and they can mean a first step towards more accessibility.

    Also, Joe Clark's session at @media had a lot of good points on this.

  • Robert Nyman says:

    Faruk,

    When it comes to the embarassment factor, I'm not sure that it is motivation enough from a financial point of view for the companies.

    What I wanted to touch with mentioning Google was that the code level of the Google web site itself is sub-par, but that doesn't stop them from being the most popular and succesful search engine. But maybe that's not what you were adressing…

    One point, however, that I think you do have is that getting a higher ranking at Google, through changing URI structure, having better structured content etc, might equal money.

    And, let's be honest, money is the key factor to get companies interested.

  • Accessibility shouldn't be a goal, it should be a way to achieve a website's goal. I've found convincing people quite easy if I can translate my wishes to their pocket holding the money.

    Why accessibility, sir? The activities aimed at improving the accessibility of your website result in a better acceptance by search engines (sadly this argument seems to be the most important for many) as well as being more accessible for users.

    Clients can translate the former easily, but if you put emphasize on the fact that the latter results in allowing a larger client base to make use of their services, they tend to quickly realize that that means more potential revenue / exposure (mostly for non-profit organisations). Besides that, it'll add to a company's goodwill and whatnot the terms used nowadays in the accessibility hype.

    My point is, clients don't care because they simply do not know why they should care. In the end, all they care about is money. Does improved accessibility help them make more money? We all know it does — they don't.

    I've found it's extremely important to keep away from telling the details. Don't tell them how you're going to do it, unless you're talking to an IT manager. Tell them why, how much it is going to cost and what the benefits are.

    Another thing I've found is that you do not want to mention the word: disability. Once you do, they are eager to put those group of users into their own corner, guesstimate the percentage that group is of their total marketing group (if it's included already) and decide whether they should care about it or not. Instead, I like to refer to them as "users using alternative ways to browse the internet".

    Regarding the Google argument, ask them one single question: Are you a search engine? Just make it clear to them that Google is a completely different company with a different target group, different goals, different services. We're not building a website, we're building your website.

    Just my two cents.

  • Robert, I was addressing a slightly different issue, yes. Not Google's site itself but Google's dealing with sites despite being crap.

    On the issue you addressed in the post, Google's site is extremely simple and it DOES work as far as accessibility goes. They may have shitty code but their site IS accessible, unlike most companies' sites, which are far more complex, have far more content and navigation, and are often simply not accessible because they use crap code that doesn't take accessibility into account. Google does. They just don't care about pretty code, but they do care about accessibility.

  • Kalle Wibeck says:

    Hello Robert!

    That was a nice sum-up! Especially your reflections on how hard it is to actually get paid for doing the "little extra" in the name of accessibility. The same problems show up in all different areas of interest:

    Usability, Target Group Focusing, Information Structure, Website Traffic analytics, Graphic Design etc. etc.

    The point is:

    It's very rare that a client actually understands that quality costs! How come? Is this a relic from the crash of the dotcom era, when a lot of webdesign agencies did a lot for a penny just to have something to do? I dunno…

    And of course: (I almost forgot ;)

    Microsoft .Net in itself doesn't renderer faulty HTML, that's done by the built in WebControls and WebForms, upon which the CMS mentioned above, base all of it's presentation.

    Isn't EPiServer CMS a real mess when it comes to separating content from presentation ;(

    // Kalle

  • Robert Nyman says:

    Jeroen,

    Thanks for your input!

    The situations and reactions you describe are very similar to the ones I've had.

    And you're probably right that how to "get away with it" would be to do it without the customer knowing. But is that the way to go? Should we have to sneak in enhancements?

    Faruk,

    Yes, there's a difference betwwen Google's web site and a complex company web site.

    But the general problem is that everyone takes after the big players, like Microsoft and Google, and if they don't deliver correct code many other developers won't do it either.

    Kalle,

    Welcome here, and thank you!

    Quality does cost, but compare the cost of doing it right the first time around to having to constantly fix errors and updates as time goes along.

    You're totally right about Microsoft.NET, I was just simplifying. The problem lies, as you say, in the WebControls and the WebForms.

    I don't want to say more at this time, but at least I can say that the <acronym title="Content Management System">CMS</acronym> mentioned above is indeed EPiServer…

  • Robert,

    Very easy solution: just explain how Microsoft has been creating accessible Standards-compliant pages for a while, now. Microsoft.com's homepage has gone CSS and semantic markup. They're not doing it perfectly yet but they're very far along, and doing a great job.

    It just shows that Microsoft understands the need for accessibility, too, and they're working on making their websites accessible.

  • Robert Nyman says:

    Faruk,

    True, Microsoft seem to have started to move in the right direction. But they still have a way to go.

    Never the less, their controls in their major web development environment Microsoft.NET(in its current version), as mentioned above, doesn't generate valid <acronym title="eXtensible HyperText markup Language">XHTML</acronym>/<acronym title="HyperText markup Language">HTML</acronym>, their inline content editing in <acronym title="Internet Explorer">IE</acronym> generates invalid code etc.

    This means that we have many years to deal with this before the improved products reach the market and get a sufficient spread.

  • Robert, I am not sure if I'd like to call it sneaking in. If you agreed with the client to improve accessibility and the client is aware of the costs (money- and time-wise), then any accessibility enhancement is perfectly valid.

    What I meant with not saying what you're going to do are things on a much more detailled level, such as providing a print stylesheet (if such a thing would actually fit under Accessibility, but you get the idea). Explaining changing URIs is perhaps the border in terms of detail, as its impact can be relatively great.

    You only need to tell as much as the client needs to know to conclude that it will help them accomplish the set goals for the website. Just like you only want to know if a car is suited for you to go off-road — you're generally not interested to know what makes the suspension so great that you can do such a thing.

    Clients don't want to know how and why it works. They just want to know if it works and how much it will work and still know a couple of details so they feel involved in the process. Furthermore, I think mutual trust in eachother's expertise should prevent situations where you'll find yourself explaining everything.

  • Robert Nyman says:

    Jeroen,

    Ok, then I understand you.

    But I'm afraid that if you even mention the word accessibility, without going into any detail whatsoever, they will go:

    What's that's gonna cost us?

    The usual follow-up to this is the directive to skip any accessibility enhancements if it's coing to cost anything extra (this is of course in a scenario where you and the customer never have discussed accessibility at all in the first place).

  • Robert, of course that's what they're going to say. As I said in my first post, it's our job to explain the ROI in such a way that the client will realize it's worth it. Obviously they're not going to go through with it if there's nothing in return for them — we know there's definitely something in return.

    Going for proper accessibility on a website has an actual purpose for the client as well. Perhaps the huge amount of discussion on this topic and how it affects the user experience, made us forget that? Realistically, we're still building a website with the client to accomplish their goals, not the user's goals.

  • Robert Nyman says:

    Jeroen,

    True. But I'm looking for some strong arguments except for the search engine one. Hence the post. :-)

    Just being accessible won't cut it for many companies out there.

    Realistically, we’re still building a website with the client to accomplish their goals, not the user’s goals.

    Absolutely. Well said.

  • Robert, we all know the benefits of improved accessibility. It's a matter of translating those to the client's pocket. I think I understand your problem though. If you go too much into detail, you will have a hard time doing that translation.

    I tend to see it as a package with some key advantages for both the user and the client. The search engine benefit is an example that's already translated to something the client will somewhat understand. Another example of improved accessibility is the increased userbase that is capable of using your services, thus becoming potential customers.

    Depending on the type of company, it might be an idea to also aim at a company's image — innovative, market leader, easy to use. Putting accessibility high up on the list of priorities could emphasize the company's image.

    It's difficult quantifying the RIO of accessibility though, but we'll get there .. eventually.

    Sorry for ranting so much, but I find communication with a client a really interesting (but difficult) subject. :-)

  • Robert Nyman says:

    Jeroen,

    On the contrary, I'm glad for your input!

    Generally, I agree with the above, but, as you say, it is hard. But definitely an interesting subject!

    As you state, the big problem is:

    It’s difficult quantifying the ROI of accessibility…

    (I took the liberty to change RIO to ROI in my quote. I guess it was that you were going for… :-))

  • lol. Yes, I was. Thanks for the change ;-)

    I suppose the direct benefits of accessibility are quite straight-forward, so I can't think of anything really than the two mentioned above. We shouldn't present them as anything more difficult either, but there are many ways to 'sell' it to a client.

  • Robert Nyman says:

    Jeroen,

    Yes, there are many ways. :-)

    I do wonder how many companies actually know anything of/care about accessibility as it is today.

    That's why I wanted to have this discussion, from the business point of view.

    Not why accessibility is good per se, but how we explain to the customer how it will gain them, both image-wise as well as economically.

  • No time to write a long comment right now, but there are a couple of things that I think are important:

    1. Accessibility is not just about disabled people, which is what many business owners (clients) think. It is about making the web work for anyone with any device (browser, operating system, whatever). That is, maximising the number of people that can access the site (more potential customers).

    2. By using best practices now, the site will live longer, be easier to maintain, and much easier to redesign when the time comes for that.

    I have a decent amount of experience with the CMS you are talking about here, and it is reasonably easy to make websites based on it adhere to web standards and be accessible. But you need the know-how.

  • Well, because the internet is "mass access and retrieval of stored data" and if you want to produce a bottleneck and insult the mainstream – don't allow access to users . After all people with disabilities are not exactly a niche group.

  • Matt Robin says:

    Accessible sites broaden the potential customer marketplace and cleaner code also validates better – gaining higher search engine rankings = more chance of it being found by…more potential customers!

    These are the simple facts that should be levelled at big corporate sites…Accessibility can equate to better profits, and that must be music to their ears right?

    Roger: "…Accessibility is not just about disabled people,"

    Totally true – and I agree that too many corporate players only look at Accessibility in this way. (How else can you explain why Accessibility isn't embraced enough by them?) It's shamefully true isn't it? Human nature?

    But this could also be said in reverse (sort of – not literally!)…if corporate websites have that view of what Accessibility means – then maybe so do a lot of customers. And that could be exploited: 'Show that your site cares about Accessibility – and you've won the moral high ground'…customers will think of this as a 'caring side' to the organistation = good, nice people to work with/buy from!

    I'll make a nod to a point in Robert's intial blog post though, just saying that a site is meeting 'Accessibility Standards' – just so they can appear to look good and win more customers is worse than not being accessible at all.

    I agree with Faruk's comments on Google (I don't need to repeat them).

  • Réflexion intéressante sur l’accessibilité des sites web

    Un appel à l’aide de la part d’un excellent concepteur web qui se demande, en tout sincérité: Comment justifier l’investissement dans l’accessibilité d’un site web? Où sont les arguments d’affaires convaincants, ceux qui dépassent la possib…

  • Martin S. says:

    I've encountered far more than once the disadvantages of ASP.NET and web standards, but have managed to create a site on my own using Microsoft's technique and yet my site's validating. I don't really know how much .NET-based CMS:s there are out there, but your post here proved me again – something needs to be done and that's why my sparetime project this summer will be building a .NET-based CMS on my own. (At least I think so ;) )

    However, Microsoft have listened to web developers, because the .NET 2.0 BETA engine already creates code that follows the web standards better than now (thank god from that, there might be a future for us .NET developers too in the future).

    Considering large sites and their lack of knowledge when it comes to accessibility – that's really a pity because so much more can be done!

    And what screws me up very much is web consult companies in Sweden (and probably elsewhere too)doesn't know about accessibility and web standards at all. Well, they should!!

  • Robert Nyman says:

    Roger,

    I toally agree with the things you mentioned as important.

    Regarding the <acronym title="Content Management System">CMS</acronym> in this case: No, it's not that hard to make it deliver validating and accessible code. But know-how isn't the only factor needed to achieve that; the will to do it and to invest the time necessary has to be there too (which it isn't in my current project).

    Also, shouldn't that be in the product in the first place? Why should one have to tweak a product's output code just to get it to deliver valid code?

    Mr Wellock,

    After all people with disabilities are not exactly a niche group.

    True, true.

    And I'll make sure to use the bottleneck argument a soon as I get the chance! :-)

    Matt,

    Your first paragraph is brilliant! It sums it up pretty well.

    And I think Roger expressed in his Accessibility charlatans post what I also feel about companies that just use accessibility for PR reasons and then not delivering.

    Martin,

    Generally, I think .NET is a good developing platform, except for when it comes generating the interface code. And I also have my hopes for ASP.NET 2.0! :-)

    When it comes to web conultant companies in Sweden, I also find the almost total lack of knowledge appalling and hard to believe.

    Good luck with your <acronym title="Content Management System">CMS</acronym>! :-)

  • Kalle Wibeck says:

    I see that there is a need for a simple/yet powerful .Net based CMS here.

    Maybe even a CMS that has a total separation between content ans presentation, for instance a layered content structure like:

    Database -> XML -> XSLT -> XHTML.

    Maybe with the addition that you also should be able to jack-in your own user-controls for more advanced features…

    This CMS already exists and it's all GPL!!!

    The drawback is a Ms SQL Server dependency, but on the other hand – from now on you get SQL Server 2005 Express for the cost of nothing.

    The current version of the CMS I'm talking about doesn't feature a valid Content editor, but a pre-delivery XHTML validator are in the pipeline.

    It's not 100% perfect and accessibly enabled, but it's close – and it's free…

    Doesn't that sound a bit interesting?

    (No! I'm not responsible for it's existance, I just happend to like it a lot! ;)

  • Robert Nyman says:

    Kalle,

    Are you maybe talking about the Rainbow project? Or something else?

    But even if such a system exists, it's not the optimal solution to it all. I think we need to affect product makers to upgrade their products so they generate valid code.

    Take EPiServer mentioned above for example: they have hundreds of installations here in Sweden and a broad customer base. The answer isn't to try to convince existing customers to switch from EPiServer, but rather to make the people responsible for EPiServer update their product to output correct code.

    Either way, I'd really like to generate all the interface code from <acronym title="eXtensible Markup Language">XML</acronym> with <acronym title="eXtensible Stylesheet Language Transformations">XSLT</acronym>, partly because I know <acronym title="eXtensible Stylesheet Language Transformations">XSLT</acronym> well, partly because it allows total control of the output.

  • Kalle Wibeck says:

    Robert,

    No, it's not the Rainbow, infact it's quite unknown to most people (it's mailing list meerly ha 93 subscribers).

    The system is called "Umbraco" and are initially developed by three danish guys.

    The product are currently in a kind of dev version but the upcoming release will be much more complete and absolutely has a huge potential to become widely used.

    Some of it's features:

    (Some from the upcoming version marked *)

    – Total XSLT driven presentation.

    Your own Controls will output XML to Umbraco.

    Umbraco don't render any HTML at all

    – Content type handling (no built in content type negotiation tought…)*

    – Very fast publishing routines.

    – Real URL's, no "nonsense" like "/templates/TextPage____1234.aspx"

    – An extension packaging/distribution interface for easy installation of addons/extra modules.*

    – Admin interface currently available in 8 languages.

    – Fast Lucene based search engine.

    – E-Commerce module

    …more to be found from the URL mentioned above…

    BTW: Umbraco has been mentioned by cmswire

    Try it out and post any reflections here if you wish, or mail them to me directly…

    // : ) Kalle

  • nortypig says:

    Robert

    The accessibility side of the site is too often ignored by big players. Quite often the examples we put up for web standards and accessibility aren't the best either. While I can see that companies or even small businesses can't come all the way in one hit you might want to run back through CSS Vault, Stylegala and CSS Beauty and see how many don't validate by a long shot. Not trashing them, they do a good job, but I've noticed that if we award praise to imperfect sites (such as the Swedish one you mentioned earlier) then why would company x up the road not want to emulate the bad practise. Hell the other guy got an award or showcased! But that's probably just an aside on this conversation.

    Basically my issue is that many businesses claim many things and there's no one place of certification to say if say a site is or isn't accessible. Some will say they're triple A accessible and don't even have resizable fonts or alt tags. When you ask them directly they say, naturally, of course its accessible or you wouldn't be on the site. So they don't actually understand or want to understand the issues. Check out this page over at Squiz.net, it's in their portfolio under W3C Compliancy… Squiz W3C Compliancy

    This government site is 2nd on the compliancy portfolio New South Wales Alcohol Summit

    it throws a mere 131 error at HTML 4.01 Transitional and gives half a dozen CSS errors

    Yet obviously Squiz believe they have a standards compliant site. Hey it's got a DTD, maybe from seeing highlighted sites they think that's enough. Hell there's probably worse on Stylegala or somewhere at times.

    So, while the nice part of me would like to believe that we're getting somewhere, I'm afraid in a lot of respects you're right. You can only build with the tools you're provided by your employer and if they don't want to pay for accessibility then you can't really force them. Also, to confuse the issue there is a long way to go with education because many many businesses don't understand – even IT businesses.

    To compound the issue we hear a lot about laws and suits but has anyone been successfully sued here in Australia since the SOCOG 2000 Maguire case? So really the further on we go businesses see no teeth are in any laws about accessible websites, here and at this time. I can't speak for elsewhere. Meanwhile government, who pass laws, hire people to use CMS's like Squiz to do their own sites and often just believe someone from their own word they'll make a great site that validates and is accessible. What they hey, once they've got the money they run.

    Another example is Reliance Petroleum who asked for all of the above, were assured and yet they can't even get it working the same cross browser. The validator chucks out around 200+ errors and turn javascript off and they have no navigation bars on the main page. So the company that designed it outsold the standards compliant vendor on the day and charged $10,000 more.

    I really don't know what the answer is here, and I'm just a nobody small fry in the backwoods of nearly Antarctica. But education needs to be addressed before anything.

    Sorry, I agree with what you wrote and I'm ranting off on tangents. Maybe we need an ititiative of it's own like the WaSP to educate and pressure governments. Is that the key?

  • Fredrik says:

    I'm also working with .NET at the current class I'm attending. You can get pages to validate, and yes, it is more work. But allow me to smash a myth: Validation isn't everything.

    I'm fairly sure JAWS won't break over a faulty meta-tag generated by .NET.

    If you build your document after the recommendations and make it accessible by (just a quick runby, not all things here):

    – Define accesskeys for your navigation

    – alt="" and title="" attributes for images and/or links.

    – Try to present the contents first in your source order (big one that even a few "CSS gurus" miss out on).

    – If else, output sane "Skip Links".

    – Try to keep tables out for any type of layout.

    – Keep images that's there for design out of the content.

    – Not make your site dependable on javascript or images to work.

    There's a other things to consider, these were just some. Then we have the issue of visual design for accessible sites, but that's not really what you were asking for, was it?

    As you can see by the points made above though, it's an issue of presenting the content not getting your code to validate. I'm certain browsers don't break because of some faulty code. And as long as it doesn't ruin your attempts at accessible mark-up you should be fine.

  • Robert Nyman says:

    Kalle,

    Thank you for introducing a seemingly interesting alternative!

    If/when I get the time I hope to be able to test it.

    Nortypig,

    Thank you for a thorough comment.

    Don't worry about ranting, I'm happy to see I'm not the only one getting upset and saddened by the situation.

    Me personally, I don't think laws, government control and lawsuits are the way to go. Sure, it might make a difference but out of force. I'd rather find the best ways to motivate companies why they should do it, so the initiative comes from them in the first place.

    Maybe some kind of ISO certification would help, though?

    Regarding the New South Wales Alcohol Summit web site: one has try hard to create so many errors with the forgiving HTML 4 Transtional Doctype.

    Fredrik,

    The bullets in your list are valid points that should be considered.

    About the validation "myth":

    Of course validation isn't everything, things might work (and be accessible) anyway.

    However, to be as future-proof as possible and to make sure it works in as many web browsers and devices as possible, I'd really recommend writing valid code.

    I’m certain browsers don’t break because of some faulty code

    I beg to differ…

    Some of them even break on correct code too. :-)

  • nortypig says:

    Validation should really be the starting point. Then it's up to human checking and adopting a philosophy of awareness of accessibility features that could further enhance a site. Failing a validator might still leave your page working but be honest and pull off the doctype lol.

    Why have a line saying you conform to a Doctype at the top of a page if you never plan to meet it?

    Or on the flip side just whack xhtml 1.1 doctypes on your page and ignore them.

    Fredrik, saying validation doesn't matter is only true in the sense that you don't care to make valid markup in the first place. Logically interpreted, anyway.

    Yes alt="" will get you over the validator too, so will writing invalid code with javascript after the page loads… alt="" is only recommended for images that are superficial and decorative, if an image means something it needs alt="something meaningful". Also, accesskeys aren't recommended as they interfere with pre-existing short cut keys and are inconsistent across platforms. Accesskeys cause more confusion than they are worth and are actually inaccessible to some degree. But yes there are a lot of things to consider beyond validation…

    Also, accessibility is about being accessible to as many browsers as possible (within sanity and ability), or trying to. As well as being accessible to cognitive, intellectual and physical disability.

    So yes Fredrik it's a big field.

    If you write invalid code then your site may work fine – but it has more chance of being more widely accessible across platforms if you do.

  • nortypig says:

    Oh and no I don't recommend writing invalid code after the page loads. That's just hiding bad stuff and tricking the validator. Sorry I should have written that bit in…

  • Matthijs says:

    Robert, a good thought-provoking article and a great discussion here. If I may, I would like to add another point of view:

    There is a lot of talking about how to convince people/businesses to spend the extra effort and money to build accessible websites.

    However, I was thinking: how much more effort is it really? The points Fredrik taks about, and validating the code, isn't that what "we" allready do? How much more effort is it, while you're writing the code, to add an alt and title tag, or a skip-link, etc? My point of view is, that building in accessibility should just be a part of the package. The client expects to get a well-build website. Well, off course we'll make sure it is well-build! Seen from this perspective, if you are in a client meeting, you shouldn't even have to tell that an accessible website will cost more. (it almost doesn't)

    But now I'm talking about the smaller to medium sized projects, in which there's much more control by the designer. I guess what you are talking about is of a whole different level.

  • Robert Nyman says:

    Matthijs,

    Thank you!

    It depends on the size of the project and the level of accessibility you want to achieve. As an Interface Developer, of course you try to write as valid and accessible code as possible.

    But one of the reasons that prompted this post is that it might not be entirely up to you; external factors might lead to invalid/not accessible code that needs work (i.e. time and money) to be fixed.

    Another thing is testing: while writing as good code as possible, you also want to take that extra measure and have extensive and proper testing of it. And many companies don't care about that, it will cost time and money. The stance is normally:

    Just surf around and see if it's ok…

    (Naturally, this surfing around is then performed in <acronym title="Internet Explorer">IE</acronym> on a PC with someone that has a 20/20 vision…)

  • Don't get your hopes up for .NET 2.0

    I work with it every day, and the amount of errors and the lack of understandig M$ has is just … sad.

    Since most programmers do not have the time, nor care about customizing the output of the builtin controls in .NET, there will be lot's of crappy sites out there for a long time to come.

    And I'm building yet another one, even though it pains me.

  • Fredrik says:

    Check out this article, found by googling a bit. It probably doesn't solve every issue out there, but it's nice to see that some people at least are on that case already.

    I see we stirred up some discussion about Validation and Accessability. Now, I'm with the Web Standard gurus on this. Accessible code and Layout. I try to validate after XHTML 1.0 Strict at all times.

    Something I noticed though, is that writing a semantic, accessible HTML-document isn't hard. Writing valid, cross-browser (can't believe we still are forced to use that term) CSS is another. Here we can really spin off the discussions about Visually Accessible layouts.

    Also, nortypig. My point is that while validation does matter, it shouldn't obstruct you too much. If your site is accessible, and still doesn't validate it shouldn't be the end of the world. Yes, browser quirks might occur. But this seems to be a visual issue. Screen Readers and Text-Based browsers for instance seems to be pretty sloppy on interpreting HTML (probably forced to by all table-based layouts).

    You can write three nested tables, slap images in the cells here and there and make a menu consisting of javascript implemented roll-overs with no alternative content. It doesn't make the site any more usable, even if it validates as XHTML 1.0.

    Likewise, say you've written a perfectly semantic XHTML 1.0 Strict template and .NET (or other CSM) outputs one table, attribute or what-not that doesn't validate. Most likely every browser out there won't choke on it. And hopefully it will still remain accessible. It's a lot of hopes up, but seeing how we can never directly control our user environment all we can do is hope really.

    Too much factors in to be able to make assumptions about our users: Psychology, Impairments, Education, Platforms, Customized CSS-stylesheets, Images Off/On, Javascript On/Off. All of these (and a lot more) are a part of accessability (and usability).

  • Robert Nyman says:

    Morgan,

    Don't say so! You're just making me sad (I haven't had the opportunity to test it for myself yet, unfortunately).

    And I feel your pain with your current project.

    Fredrik,

    Yes, there are some ways to make ASP.NET's output code valid, I will write about that in due time.

    Of course "just" valid code isn't the solution to a perfect web site, you need to have a understanding of semantics, <acronym title="Cascading Style Sheets">CSS</acronym> and its implementations on the different web browsers and a myriad of other things.

    But valid code is one of the pieces of the puzzle to get there.

  • Fredrik says:

    That's exactly what I wanted to state, Robert. Accessible layout isn't based on Valid Code alone. Yes, it is very important to try. But if the validator chokes on some (hopefully) minor attribue, I suggest leave it for now. Especially if you're forced to push a deadline just for validation.

    Also, semantics is, in regards to your original question is a wonderful argument to convince fellow coders. At my school our new teacher is extremly demanding that we have coherent naming of classes, objects and functions. This all falls together with using a for headings instead of a table with a class assigned to it. And using classes and ID:s named after function not form.

    The teacher is now eagerly listening to everything I havet to say about webstandards :p.

  • Robert Nyman says:

    Fredrik,

    Good that we agree! :-)

    When it comes to some minor attribute not being valid, it depends on the situation and your own and/or your customer's demands.

    In my current project, I have to except the attribute warnings and their likes since there's nothing I can do to change them (at least I only have warnings as opposed to actual errors. So far…)

    Your teacher seems to be a good person, by the way! :-)

  • Franck says:

    Arguments for accessibility TODAY:

    – Legal obligation

    – Better seo potencial

    Muti-devices access: Mobile & PDA's are still unsignificant as of today. This will be a market in the future in Europe. Other access devices just too anecdotics (not referring to robot engine)

    The question of using non standard compliant cms is related to accessibility but is different according to me. Using web standards is just coding better, and this has a clear ROI both in terms of user experience & maintenance expenses. Any business owner will understand what is a standard, and associate this label to Quality

    The business case for accessibility is for me not very clear. I guess the best thing that could happen to WAI would be that the market understand that coding with web standards means:

    CSS based layout

    Valid CSS

    Valid xhtml

    WAI AA

    508

    Don't sell accessibility alone, sell it among a Web Standard Package

  • Robert Nyman says:

    Franck,

    I agree, it should be a part of the package.

    But customers will then, to trim costs, ask what specifically is part of the package, see accessibility and want to get rid of it if it's costly.

    But the SEO argument seem to be one of the strongest one, I agree.

  • Fredrik says:

    Legal Obligation doesn't apply everywhere. And in most cases, it only applies to government related websites sponsored by tax payers money.

    Indeed it's a valid argument though. Studies made obviously showed that disabled people use the same products as everyone else. Even visually impaired go to movie theatres.

    Sometimes I've made the analogy of architecture to my classmates. For instance, when you build an office you don't put the entrance six feet up in the air with no stair to it. OK, they do indeed build a stair. But what about the wheelchair ramp? It's OK for anyone who can walk in, but what if you're bound to a wheelchair?

    Same thing you can relate to websites. For instance, a company adds a browsercheck that neglects all browsers except Internet Explorer and Netscape (old-school browsercheck :)). The take the advice from users and skip it. Still using a lot of Flash and images for navigation and no alternative content. There you have your ordinary webpage, but convert it to webstandards, and it will also have a wheelchair ramp.

  • Robert Nyman says:

    Fredrik,

    As I wrote above: Legal obligation might apply in some cases, but I don't think it's the number one argument in those cases where it's applicable.

    I'd rather see companies building accessible web sites because they see a meaning and future in it.

    And yay! for wheelchair ramps! :-)

  • Adam says:

    I can think of several good reasons why you want to design accessibly:

    1) The techniques you employ to produce accessible sites (CSS Layout, semantic markup) will allow you (if you choose) to design sites that are much smaller. We found that we averaged 35% bandwidth savings (this worked out to be tens of thousands of dollars each year, i believe). This is a big deal unless you have the lowest fixed bandwidth cost for your host and don't come close to using it all.

    2) Accessibilty is as much about design and organization as it is about markup. An accessible design typically makes for a better, more usable site for all your users. That is to say, they'll find the information they need (which I assume will translate into value for the company) faster and easier. The perception will be that you are more responsive to your clients.

    3) I'm not 100% certain but something like 10% of the population of some sort of disability. To this group, you must add the rapidly growing group of aging baby boomers. What is the cost of conciously ignoring 10% of your potential customers?

    4) If you plan for it from the very beginning of a project, and make intelligent, informed decisions (like avoiding content management systems that do not provide validatable, or at least customizable, results) it costs no more than doing it the old way.

    5) I'm no lawyer but I think that we will soon be hitting the point where the techniques for creating accesible sites is sufficiently well known and distrubuted that one could sue a company for discrimination based on existing laws (rather than waiting for new laws to be written). Most existing laws (from my understanding) require a reasonable effort, and the effort, at this point is relatively minimal.

  • Small Paul says:

    Note that code can be invalid, but still hit many of the W3C's accessibility guidelines.

    Valid does not equal accessible. (Although validity is a priority 2 guideline.)

  • Robert Nyman says:

    Adam,

    Thanks for your input. Very valid points.

    Small Paul,

    You're absolutely right, and it shouldn't be mixed up so people think it's accessible just because it's valid.

    But as I stated above about how to create, in all aspects, perfect web sites:

    …valid code is one of the pieces of the puzzle to get there.

  • nortypig says:

    Mmm I'm sorry if I led anyone to think I inferred validation is accessibility. I think we all know that it goes way beyond that. It's not bothering to try that worries me…

    My point regarding validation was actually that many of our showcases for web standards practises actually put up sites that dismally don't validate. So big businesses and other developers say what the hey it's got a Strict DTD with one hundred errors lol. It's interpreted as good enough. I know it was a tangent rant but that's what I was getting at. Not that accessibility is reliant on validation itself. Even Bobby had a disclaimer rant that you have to do human checking..

    The bottom line is that good well thought out standards sites that validate and then go forward to address accessibility factors which enhance the site for all users is optimal. I too create XHTML 1.0 Strict sites. But businesses don't care about accessibility. If accessibility includes getting it working on less supported browsers, for instance, then I'm not working for free. Accessibility does mean browsers too.

    The same goes for anything in the process of creating websites though such as addressing the underlying Information Architecture or how much testing or the level of documentation. In the end you can only address what you're paid to do. That get's back to the original thread a bit.

    In Robert's original article he identified the deficiencies, and yes they're all addressable, but the boss won't pay you to do it so you either do it on sundays or not. That's the real business world and not school idealism unfortunately. Every hour of free stuff I do is time away from my real life.

    Really we need to look at ways of educating businesses to understand accessibility, to see it as actually more than a wheelchair ramp on a building, and give them some solid financial business reasons to employ best practise developers. Whether they listen or not it's their option and their site though.

    With business they don't care about coding, that's our end. They glaze over usually when you talk geek. But mention better Google indexing or bandwidth savings on larger sites especially their ears prick up. Money drives business and businessmen generally. Some great arguments on this have already been put forward.

    But no, validation isn't the be all and end all. I'd say it's the beginning though.

  • nortypig says:

    I'd go so far as to say if you're purposefully not bothering to validate and don't see the point in creating valid code then why would you bother about accessibility? First i create valid code then I make sure it's supported cross browser as best as I can and then I look at ways of making that site even more accessible with enhancements. And I'm learning new things every day that I incorporate. Such as accesskeys not being regarded as best practise anymore.

    Another business factor is I'm not going over all my old jobs to put the new stuff into them for free lol.

    This is a really good thread by the way Robert and thanks for the email. It's good to question why sacred cows are sacred occasionally.

  • nortypig says:

    Andy Clarke's latest post might interest you Robert

    He's very much against legislation on accessibility, too. I liked the way he peeled off government and commercial sites. I'd have to say I'd expect more from a government that I pay taxes to than from a business that may or may not want my business.

  • Robert Nyman says:

    nortypig,

    Thank you!

    Not that accessibility is reliant on validation itself. Even Bobby had a disclaimer rant that you have to do human checking..

    That’s the real business world and not school idealism unfortunately.

    But no, validation isn’t the be all and end all. I’d say it’s the beginning though.

    I’d go so far as to say if you’re purposefully not bothering to validate and don’t see the point in creating valid code then why would you bother about accessibility?

    are things I just wanted to quote because I really liked them! :-)

    When it comes to the one about the real business world as opposed to school idealism, it's extremely valid. In theory, or in a closed and controlled environment, creating valid and accessible web sites isn't that hard. It's the real-world scenarios with business factors, third party content etc that make it tough on us.

    Also, I'm happy to find out that Andy Clarke and I have the same standpoint about legislation!

    (I took the liberty of linking your text instead of writing out the full URLs in your posts)

  • nortypig says:

    Roger Johannson just posted a relevant piece this afternoon too, coincidentally. Well kind of relevant.

    Web Standards vs Accessibility

  • Bryan says:

    I haven't read this yet, and I would never condone scare tatics, but it is a reality that in the future, we could possibly see laws stating that all websites must meet xyz accessibility standards. The disabilities act could definitly play a factor.

    You could always state to a client to try and convince them something like this

    By including accessibility into your site, you not only attempt to reach the greatest number of users, but you protect yourself in advance for any accessibility laws that may be passed in the future. Its important that everyone, handicapped or not, has access to the same information. Condoning to accessibility rules not only can better yourself on search engines, but can place your company higher on a moral factor and could be recognized as such in the future. Aside from extra time placed into the project, there really are no negatives to taking this route.

    Or something along those lines.

    Just my 2 cents.

  • Fredrik says:

    Bryan, I think a statement like that would work in an ideal world. I have deal mostly with small firms, most of them have no knowledge about the Internet and they listen eagerly.

    But I have a friend, not particulary close who probably is the worst client ever how have had some trouble with the fact that my layouts aren't as backward compatible as table layouts, so I have to use every css-hack in the book to get it too look the same in old Netscape installations to IE 5. Naturally, he calls often pointing out this and that after he has visited some friend or a public library.

    Each time I do my speech about accessability. He often replies: "Yeah, yeah, whatever. Can't you fix it now?"

    This is a rince-and-repeat progress. I could have fixed it the "easy" way and just let IE 5 users get a "light" version of the site, but not for this guy.

    This is the problem. Tables looks the same, everywhere. And most clients just care about what they can see. Not what others can't see.

  • Fris says:

    I thought that one of the defining pro's to using CSS was that it made the development / design factors more inexpensive than other routes.

    However I can see when your speaking of a site that has allready been built poorly , re-dedicating funds to correcting the problem is where the real issue is.

  • Robert Nyman says:

    nortypig,

    Probably not a coincidence, he's a friend of mine and we're avid readers of each other's blogs (or at least I am of his! :-)).

    Bryan,

    You mention good and valid points. The only 'but' is:

    Aside from extra time placed into the project…

    And extra time equals extra money equals someone responsible might pull the plug to save money (unless above arguments have convinced them they'll win back that money in the long run).

    Fredrik,

    I feel your pain!

    And most clients just care about what they can see. Not what others can’t see.

    So true. Then one has some hard work trying to get them to trust your professional judgement in making the calls, show them web browser stats and so on. But it's not easy.

    Fris,

    I thought that one of the defining pro’s to using CSS was that it made the development / design factors more inexpensive than other routes.

    Well, yes, that should be one of many pros.

  • Robert Nyman says:

    This might be useful for some of you, by the way: color blindness simulator (thanks to Per at Gamepepper for the tip).

  • Reto says:

    Accessibility is not only an ethical question, it translates into sites that are easily accessible by "distance-challenged" people.

    One of the accessible sites I created was also tested (mainly for fun) with a variety of mobile phones, Palms, Windows CE devices (and browsers). Even WAP-browsers were able to display the content properly and readable.

    Consequently, accessibility also means that I do create websites for mobile devices. Sure, I could go the .NET approach of creating an extra-site and using the extra-"Mobile Controls" – but hey, my name is not Jack Bauer – I definitely cannot work 24 hours a day. :)

    Sure, I am schizophrenic enough to create framed sites and table layout for quick and dirty products – whenever the customer wants this. When the CEO requests: "I want the menu to be sticky at the top left, like the one on the [framed] site of my son". Well, I do it with frames.

    Finally to answer your question "Why accessibility?", I also think that the (Internet-)world moves forward only. The day, I don't want to move along anymore with new techniques and technologies, I probably will change the job. This is why I believe in accessible web design.

  • Robert Nyman says:

    Reto,

    Good point. And nice reference to Kiefer Sutherland; we don't see many of those in web developer's blogs. :-)

    When it comes to your specific problem with a fixed position: use position:fixed in CSS for competent web browsers and the fix for position:fixed in <acronym title="Internet Explorer">IE</acronym> that I link to in RobLab's CSS page.

    Also, I definitely agree that the day you're not willing to move on and evolve, that day you should stop working with the web.

  • Jim says:

    Well, Google seem to do pretty good. And if they don’t care about web standards or accessibility, why should we?

    a) If a browser breaks on Google's invalid code, the browser is dead in the water and will never see the light of day. If a browser breaks on your little client's website, the problem gets put on the end of an infinitely long to-do list of things to work around and the browser gets released to millions of people anyway.

    b) Does your client have Google's resources to fix any problems that might crop up? Do you have a large testing lab of myriad different combinations of browsers, operating systems, video cards, etc? (Not kidding: the type of video card triggers certain problems, e.g. Gecko's infuriatingly slow scrolling with fixed backgrounds).

    Google get away with it because they are huge. Most organisations simply don't have that luxury, so saying "well Google does it" is nonsensical.

  • Robert Nyman says:

    Jim,

    Thanks for your input.

    Personally, I think that if major players like Google and Microsoft don't follow web standards and if they aren't making accessible web sites, they're setting the bar for many companies that will imitate them.

    If you are as huge as they are, you have a certain responsibility in what you deliver.

  • Jim says:

    Oh, don't get me wrong, I'm not saying that what the big players do is right, I'm just saying that their situation doesn't apply to 99% of web developers.

    Personally, I think that Google is in a unique position to promote adherence to the W3C specifications. Imagine the effect it would have on SEOs if Google said that they work better with valid code.

    Unfortunately, Google have a vested interest in keeping the status quo. So long as it's difficult to make sense of HTML, Google has an advantage over everybody who has less resources than them to throw at the problem.

    Not that I think Google are doing it deliberately, one look at the typical code they use makes it fairly obvious that their skills with HTML/CSS/Javascript aren't very advanced. Sure, they can build _complex_ web applications, but they do it by throwing lots of code at the problem instead of throwing quality code at the problem. Example: browser detection over object detection. Ick. Straight out of the mid 90s.

  • Robert Nyman says:

    Jim,

    Ok, then we're on the same page! :-)

    And yes, it would make a huge difference if they went out and promoted valid, accesssible code (Google, please do).

    By the way, I wrote a post about object detection a while ago.

  • Egor Kloos says:

    I'm shocked (not very) that many don't seem to see past their own back garden to be able to take in the broader view which is dominated by money. I've have enough trouble trying to get everybody on board with separating content from structure. Fighting for accessibility could ruin everything else I have worked very hard to attain.

    If you can build a website that does that and when you also can take usability issues into account you're already well on your way. The issue whether accessibility can be financial beneficial is circumspect at the very least. To make make matters worse it's actually very difficult to defend a accessibility budget from a statistical point of view. Accessibility gains and concerns are washed aside by the weight of overwhelming support for everything else other than accessibility. Building and testing with usability in mind has been shown time and time again to be very cost effective. That should take precedence over accessibility any day of the week and twice on Sunday.

    At the moment I'll fight the ideological battles I can win. I'm just going to sneak accessibility in through the side entrance bit by bit. Content separation and usability allow me to do this without me feeling like I'm sticking it to the man. Rebelion is for the young and young I am no longer. In the grown up world I design and build websites.

  • Robert Nyman says:

    Egor,

    Welcome here!

    It's good to see that you seem to have very similar experiences to mine.

    And, as stated above in people's comments and in other people's blogs, if you started doing it right (i.e. writing accessible web pages etc), it comes natural in the future.

    Absolutely, but it doesn't take you all the way, with all necessary testing needed to confirm that and other development aspects to take into consideration.

    That's also why I wanted to bring up the money perspective, because in the real world, that's the thing in the end what decides if something is going to happen or not.

  • nortypig says:

    Have a read of Gez Lemon's post Validity and Accessibility.

    The WCAG have been dumbed down moving validation from level one to level two… (insert expletive of your choice) … and I need not say more as I totally agree with what Gez says there. Testability is a fundamental principle of software engineering.

    Thought it may be a pertinent read for those who haven't caught that one today.

  • Robert Nyman says:

    nortypig,

    I know, that is a very bad decision by them.

    And I can't really find any good reason why they would do something like that, either.

  • Our website contains numerous accessibility guidelines and might be of interest to you: http://accessibility.frecosse.com

    There is plenty of free advice about how to quickly create accessible content for websites.

  • Robert Nyman says:

    Graeme,

    Thanks for the link.

  • kptc says:

    I work for a web development company and we often have clients request that we produce an accessibe site. The ploblem here is not with the clients or even with the company I work for which is only too happy to comply and make accessible sites. In my opinion we don't have a problem with technology getting in the way since we have all the tools we need. The problem is my colleagues who don't believe in accessibility and can't be bothered to learn anything about it. They don't listen to reason and do the bare minimum if anything to fulill the client's request for accessibility. They can do this because often the client doesn't know how to properly check if a site is accessible or not.

    What arguments can I make to colleagues who aren't persuaded by the financial benefits or by improving other peoples lives? How do I persuade someone to put that bit of extra effort into developing a web site when it's not going to benefit them personally?

  • Robert Nyman says:

    kptc,

    I'm sorry to hear that. One thing that might help to tell them is that SEO and accessibility goes hand in hand, when it comes to semantically marking up your content. That in turn might result in happier client, leading to more work and in the end better security and/or salaries for them.

    And if they're lazy, writing HTML and CSS becomes way easier if you have lots of different elements, so you don't have to apply <code>id</code>s and classes all over.

    Good luck!

  • [...] Why accessibility? [...]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>