Adding vs. not removing accessibility
As Jeremy Keith states in The language of accessibility, accessiblity is something that is an inherent part of Web documents that make proper use of semantic HTML.
Far from being something that is added to a site, accessibility is something we need to ensure isn’t removed. From that perspective, the phrase “making a site accessible” isn’t accurate.
Very well put. The only sites that need to be “made accessible” are those that are badly constructed to begin with and those that once were accessible but have had too many accessibility-removing additions grafted on.
Jeremy also notes that the German word for accessibility is “Barrierefreiheit”, which means “free from obstacles”. To me that perfectly describes what accessibility is about – not creating barriers that will make it difficult for people or machines to access your site’s content. The Swedish word for accessibility is “tillgänglighet”, which just like in English is a bit problematic since saying that a site is accessible can also be interpreted as “Yes, the server is up and running, so the site is accessible.” Hardcore server-side people seem to be the most easily confused by this, probably since keeping the server running is one of their most important tasks.
To get back to the issue of making vs. keeping a site accessible, I will follow Jeremy’s lead and use keeping from now on. Most of the time, anyway. In many cases sites really do need to be “made accessible”.
- Previous post: Lame excuses for not being a Web professional
- Next post: Guidelines for creating better markup
Information, sponsorship, and externals
About the author
Roger Johansson is a Swedish web professional specialising in web standards, accessibility, and usability. More about me and this site.
Latest articles
- Validation statistics from Nikita the Spider Comments off
- An analysis of the sites crawled by the bulk validation tool Nikita the Spider during March 2008.
- Authentic Jobs API and Affiliates program Comments off
- The Authentic Jobs job listing service now has a public API and an affiliate program.
- What does Acid3 mean to you and me? Comments off
- Opera and Apple have announced that their web browsers pass the Acid3 Browser Test, but how will that help web designers and developers?
- Designing Web Navigation (Book review) Comments off
- Learn the fundamentals of navigation design and design better navigation systems for large and small sites as well as for web based applications.
- DOMAssistant bundle for TextMate Comments off
- To save keystrokes and speed up development I have created a DOMAssistant bundle for TextMate.
- First impressions of Internet Explorer 8 Beta 1 Comments off
- My impressions after trying out Internet Explorer 8 Beta 1 for a couple of days.
Comments
I couldn't agree more. If we're already starting out with accessibility in mind, keeping a site accessible should be fairly easy. I guess it goes right along with progressive enhancement really.
Just a minor note: The correct term to use for those hardcore server-side people is availability, so at least in English there need not be problems.
However, the word availability when translated to Danish becomes "tilgængelighed" - just like accessibility.
Yeah the thing that gets me with this argument of accessibility is that its not like its actually any much harder to design and create a site accessible than it is to design and create a site un-accessible.
In Germany we are unhappy with “Barrierefreiheit” either because it has a negative connotation, being the absence of something negative. It sounds like a disease (some colleagues even treat it like that and won't touch it). Thus some of us prefer “design for all” because it sounds more positive. Wheelchair ramps are not for wheelchairs alone, even when they are ramps to the internet. In the same spirit, “keeping” something accessible is the better term.
That's an excellent way of putting it, I'll take a mental note not to use the phrase "make it accessible" but rather "keep it accessible"!
I think that's one aspect of pushing development using Web Standards is that accessibility is one of the benefits inherent in them.
I do think there are some fundamental UI / workflow issues that can make a site 'more accessible', or at least easier for those using assistive devices to navigate round. So a combination of Standards compliant code along with an appropriate site structure and UI helps to keep a site accessible from the start.
I wouldn't say that German developers are "unhappy" with the word Barrierefreiheit. There are of course people who think that it isn't necessary to take care of that issue, but that's another story. I think the main problem with the word "Barrierefreiheit" is that it doesn't correspond exactly to the word "accessibility". There is another word in German to mean exactly that: "Zugänglichkeit". I also want to note that "Barrierefreiheit" is also often used as "to make something obstacle free".
I agree with you that the use of these words depends on the position you are in: if you have a positive attitude towards the whole subject, you probably use "keep obstacle free" instead of "make accessible".
Agreed. Some accessibility features are built right into the (x)html specs and won't validate. I'm beating a dead horse here in saying that sites should be built using standard markup practices from the very start, as the article indicates.
Other accessibility issues (such as color schemes and content design) should never make it out of the design phases until accessible.
Well, in Czech both expressions - "pristupnost" and "bezbarierovost" are used almost equivalently. It's a good point about the actual meaning of these words.
Excellent article - this is exactly what I try to explain to my clients, especially those for whom I'm redesigning a site. For them, it's about removing the barriers that the previous designer put in.
Funny because this is how I think about it in my head, but this is the first time I've seen it talked about as "not removing" vs "adding" in a public forum.
Sorry, comments are closed for this post.