Digital Web Magazine

The web professional's online magazine of choice.

Accessibility From The Ground Up : Comments

By Matt May

January 20, 2005

Comments

Mike D.

January 19, 2005 9:31 PM

Very good article, Matt. This should be on the shortlist of required reading for everyone who is writing a lick of code on the web, but especially for people just starting out. I feel like most people (myself included) start out authoring for the web thinking almost exclusively about the mainstream web browser. Only later do we learn that accessibility is even an issue (from a moral OR legal standpoint). Sure, everyone who has been around for at least a couple of years now knows about accessibility, but it’s important to catch all the up-and-comers before they up-and-come.

Oh yeah… and gooooo sIFR!

Andy Budd

January 20, 2005 4:27 AM

Good Article Matt,

I think web designers have started using grey text on a white background to reduce the contrast slightly and make reading more pleasurable for the majority of users. Unfortunately this can adversely affect people with reduced vision. However something interesting I learned the other day is that this reduction of contrast can also benefit users with dyslexia. Apparently many dyslexic users see high contrast text as rivers of white and reducing the contrast can help comprehension. So while low contrast text can cause accessibility issues, so apparently can very high contrast text.

On a side note I’ve always been interested in how the WAI came up with the WCAG 2.0. I’m not sure if you’ve carried out any actual research studies into web accessibility (and when they were) or if you’re relying solely on expert opinion. I think it would be very interesting to WCAG users if you highlighted where each guideline comes from. In a recent study by the UK Disability Rights Commission they concluded that many common “accessibility” issues weren’t covered by WCAG 1.0. which I guess is some cause for concern, especially if the the WCAG are eventually going to be used by courts to judge if a site is “accessible” or not.

Kev

January 20, 2005 4:49 AM

Andy above me makes a very good point when he says that common accessibility issues aren’t covered by WCAG 1.0.

WCAG 1.0 also (in my opinion) put a heavy emphasis on sensory and physical disabilities and hardly any on perceptual or learning disabilities.

From my own experiences with my autistic daughter I know that an animated or graphical interface can be a massive boon to accessibility. Flash in this instance would be an ideal medium. It would be nice to see WAI addressing this issue more.

mattur

January 20, 2005 5:28 AM

Good article,

The hardest part of Web accessibility, in my opinion, is the stuff outside the angle brackets

...great to see this important point highlighted.

If you

Walt Buchan

January 20, 2005 5:57 AM

We’ve been missing this article.

I found introducing the concept of accessible design to the team I work with one of the trickiest problems I

Jan Marie Schmidt

January 20, 2005 7:32 AM

Thank you for great article.

It’s a challenge to sell accessible design to the web team but well worthwhile. Even more of challenge, for me, is to sell it to a potential client. Generally there’s much needed client education before we even get to the accessibility topic so your article will be an excellent tool in that regard.

Matt May

January 20, 2005 9:13 AM

Andy,
The DRC report, which claimed 45% of accessibility problems they found in their tests were not covered by WCAG 1.0 (or, as they called it, “the Web Accessibility Initiative Checkpoints”), caused us to take a second look at our own work. We found that 77% of their issues were covered by WCAG 1.0. And a further 18% is covered by the User Agent Accessibility Guidelines 1.0, for a total of 95% coverage of the issues in the report.

It’s the UAAG part that’s important to mention: is it more reasonable for less than 10 browser and media player development teams to integrate features that are useful for accessibility, or should millions of Web designers be made to implement features that really always belonged in the browser?

As far as WCAG 2.0 goes, it will not become a W3C Recommendation without going through what we call a “Candidate Recommendation” phase, in which we have to test our guidelines with real-life Web situations. If a given guideline is not helping Web accessibility, it’s not going to be there when it’s a final Recommendation.

Kev,
We’re trying as hard as we can to produce guidance to increase accessibility for people with a full range of cognitive disabilities. The problem is that the range is so great that something you might recommend (say, using Flash and animation) is bad for someone else (e.g., someone with ADD who can’t read content while things are flashing in their field of view). But we’re trying. That’s why it’s even more important for user testing and a good understanding of relevant disabilities to work toward more accessible design.

mattur,
Semantic coding is important. I’d put that sentence in big, huge letters — but that would require presentational markup.

That there is now no difference in screen readers and voice browsers doesn’t mean this is irrelevant. If you’re doing semantic markup, which is a key element of accessible design, then strong and em are a part of that party. I generally consider this a second-tier issue, and it gets a lot more attention than it needs, but it’s still a piece of a larger whole.

Plus, Google cares. Think of it as a search engine optimization, if nothing else.

mattur

January 20, 2005 11:04 AM

Thanks for your comments Matt. I agree that separating content/structure from presentation as far as is practical is a worthwhile goal.

It may or may not be justifiable to recommend replacing b with strong, i with em in a W3C (X)HTML markup-style guidelines document, but since this point does not affect accessibility in any way, what is it doing in the WCAG2 techniques?

IMHO If one guideline can be easily demonstrated to be, at best, misleading, it provides accessibility-sceptics with an excuse to dismiss all the other guidelines as equally misleading.

Plus, Google cares. Think of it as a search engine optimization, if nothing else.

ooooh… take that back! I’ve been doing SEO since 1996 and Google, like everyone else except markup enthusiasts, appears to regard strong and bold as interchangeable and equivalent.

Matt May

January 20, 2005 12:18 PM

mattur,
I wrote a 2500-word article and you’re getting hung up on one sentence. I see that you’re going to argue b and i. If you disagree, fine, but I’ve been sucked into this debate once (see: Understanding Semantics, Strongly Emphasizing Semantics), and it’s a black hole. WCAG 2.0 says “Ensure that information, functionality, and structure are separable from presentation“, and it does so for reasons detailed in the document. It’s important today, and more important tomorrow, as user agents wisen up to semantics. XHTML 2 obsoletes b and i for a reason.

This is all I will say on strong and em vs. b and i.

Moving right along…

John Zeratsky

January 20, 2005 5:10 PM

This is a nice resource — something I will refer back to.

I was glad to see you take the approach that accessible sites aren’t just for blind or otherwise disabled people (which is what a lot of designers think). Even the mythical “normal user” might have trouble controlling the mouse, or might view your site on a very big or very small screen. This intersects with usability to a large extent, but it still centers around making your site accessible to as many people as possible (regardless of whether we consider them “disabled”).

Mike D.

January 20, 2005 5:33 PM

Mattur: I think that the only reason b/i and strong/em don’t affect accessibility today is that screenreaders read them interchangeably (because many people sloppily code them interchangeably).

When more people use these tags correctly, it could be argued that screenreaders should ignore b and i tags entirely, since they really don’t mean anything. If a designer is using a bold tag just for visual effect, for instance, the screenreader should not put spoken emphasis on this.

mattur

January 20, 2005 8:36 PM

Thanks for your reply Matt. I have no wish to debate the semantics of the four tags either. I’m only concerned about the accessibility issue or lack thereof. I think this is a valid, and on-topic, concern.

Strong and em may only appear in one sentence, but IMHO it distorts the whole article. You take the time to recommend using strong and em, yet only mention the image alt attribute in passing references to spacer gifs and “text replacements for non-text content”. Is using strong and em really more important than effective alt text?

If using bold and italic is an accessibility issue please provide links to the user requirements analysis and/or any other research that confirms this. If there is no evidence that this is an accessibility issue let’s drop this advice from the article and the WCAG2 techniques for the sake of clarity and simplicity.

Al Abut

January 20, 2005 9:32 PM

Kudos: as a working web designer, this is a great introductory article that I can bookmark and show to clients and partners when I need them to ramp up on this important issue. It’s remarkable how well you combined the high- and low-level overviews into a concise bit of writing.

However, I was only surprised by one point, your endorsement of sIFR over the non-Flash CSS methods instead. Do you mind going deeper into that? I’ll admit to no experience with sIFR and wouldn’t mind learning more. If I was to boil it down, the differences only seem to be that CSS-based techniques fail the images-off/css-on situation whereas sIFR requires Javascript to be on. Requiring either CSS or Javascript to be turned on is probably a wash, no? So then the other con of sIFR would come into play to break the tie – bigger downloads with JS files and Flash font libraries.

Nick Finck

January 21, 2005 12:22 AM

Al: I can’t speak for Matt, but my general understanding is that font selection is very limited in a cross-platform environment, with the use of Flash you get beyond that issue… not to mention aliasing and such. The thing about sFIR is that it has no impact on the graceful degradation of the page down to the level where screen readers and text only browsers can access it. At least that is my understanding. Matt and Mike, correct me if I am wrong here.

Al Abut

January 21, 2005 2:10 AM

Nick: you’re absolutely right, can’t believe I overlooked that about sIFR – it’s an automated image replacement technique, whereas the CSS ones require hand-crafting. That’s a huge win, especially for larger sites with dynamically-generated headlines, like the ESPN site that Mike initially invented it for.

So refining some more, the only drawbacks I can see are a slightly steeper learning curve for developers and larger initial downloads for users – is that right? I’d love to see those concerns shot down too.

Mike D.

January 21, 2005 11:45 AM

Al: For people fluent in CSS, the learning curve for sIFR is like 10 minutes. Not too bad. The only arguably complicated part of the entire process is font-tuning. The rest is dead-easy. Easier than image replacement even. With regards to bandwidth, it can be argued that sIFR beats image replacement as well because users only download the 10k swf once and the 7k javascript file once. Every subsequent page load pulls that stuff from the cache.

There are also a ton of other benefits to sIFR such as selectable text, zooming, etc, but you can read all about them here: Introducing sIFR

Christopher M. Kelly

January 21, 2005 2:36 PM

Thank you! We need articles and information like this to push accessible coding techniques in our work organizations. I know from my work experience at a Fortune 500 that some developers “get it,” but managers remain convinced accessible only helps “a few people” and “costs too much.” ARGH.

Al Abut

January 21, 2005 5:29 PM

Mike: so there you go, granting all of my wishes. That leaves me with no excuses – I’m thoroughly convinced and looking forward to tooling around with sIFR this weekend.

So Matt, thanks for turning at least one web designer on to this accessible IR technique. Just goes to show that even seasoned pros can learning something new!

Juliano Moreira

January 22, 2005 2:13 PM

mattur:
Continuing Matt’s thought, a few more advantages of using semantic elements(em,strong) as opposed to presentational elementos(b,i) is that search engines interpret semantic elements as a measure of importance of web pages. Consequently, increasing the hits of your website and increasing your profit.

Jude Robinson

January 26, 2005 3:58 AM

Mike D:

“When more people use these tags correctly, it could be argued that screenreaders should ignore b and i tags entirely, since they really don’t mean anything.”

On the contrary, when used correctly they are inherent to the meaning of a document – when used in scientific notation for instance:

Mutating 284FRRG287 to 284FTTG287 causes vacuole defects of svp1Delta cells

...could have an entirely different meaning to:

Mutating 284FRRG287 to 284FTTG287 causes vacuole defects of svp1Delta cells

Here the meaning of the text could be changed if the text was not presented in specifically a bold or italic format – in this instance neither <strong> or <em> will do. <b> and <i> are every bit as semantic as <strong> and <em>, they just mean different things.

Mark Gillick

February 4, 2005 7:50 AM

I write websites with a heavy map content (GIS). I have never yet come across maps in a discussion on accessibility.

1. Screen Readers can’t read maps (at least simple raster ones, they may have a better job at reading vectors). Reading routes is a different matter.

2. I use a lot of Javascript which as far as I can tell is all absolutely necessary (zoom in, zoom out etc). All thought I could move all that functionality server side perhaps.

Where does cartography fit into web accessibity?

Mark Gillick

Will

February 10, 2005 8:27 AM

I fully understand and support using strong/em over b/i. Ironically, this form lets you use either. ;-)

Matt May

February 10, 2005 1:23 PM

Cartography is a tough nut to crack. Maps convey a whole lot of information, which is why they’re so useful to people who can see and understand them.

But there isn’t anything resembling an accessible equivalent to maps. If the primary purpose of a document is to render a simple visual map, then it can’t really be made much more accessible to blind users. Not any more than, say, a pixel-by-pixel description of the Mona Lisa could help accessibility to blind users.

However, if the map is another rendering of, say, driving directions, then textual directions are the equivalent alternative. (It’s helpful to use GET rather than POST as well, so that users can search on driving directions, for example, and then email them to someone who can see the map.)

Remember also accessibility to people with motor disabilities. Ensure that features related to scrolling and zooming on mapping data can be actuated via the keyboard.

mattur

March 15, 2005 5:23 AM

I’ve just belatedly read WCAG Bugzilla Issue 1112 and see the advice to avoid b and i has now been removed:

“In the February 2, 2005 TTF telecon, we decided to remove techniques recommending against the use of b and i elements from the HTML techniques because this was dependent on the version of the technology in use. While future versions of XHTML may deprecate these elements, b and i are not deprecated in HTML 4 and do not present a specific accessibility barrier for user agents.”

http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1112
http://www.w3.org/2005/02/02-wai-wcag-minutes.html

Thanks v.much for taking my comments on board Matt.

Sorry, comments are closed.

Media Temple

via Ad Packs