Slashdot Mirror

This is an unfunded federal mandate, requiring schools to spend money that they can not afford.

Try this tool on your website to see how accessible it is(nt).

You might be interested in reading about contrast ratios. The text is #888 and the background is #fff, and it gives a contrast ratio of 3,54:1 according to this calculator [1].

The recommendation is to have a ratio of at least 4,5:1, although personally (and I'm young and have no vision impairments) I'd say the text needs to be at least as dark as #555 to work out. (contrast ratio 7,46:1)

Blame Microsoft and web developers.

Nothing particularly new.

Well there's your problem: hidden is not a valid value for the display property. hidden is valid for the visibility property. According to the WebAIM training that I just had, both "display: none" and "visibility: hidden" should hide content from screen readers. I don't know for certain as I have never used one.

Yes, I know that, i was writing display:hiden on a phone on the train, it was supposed to be flippant. The code is actually much more complex and based around jquery, but works fine in IE8/Chrome/Firefox/Safari.

That markup correctly shows one text box on all browsers, but on our version of Jaws it "displays" 2 text boxes. This is a bug in Jaws (or some other tool) that our accessibility team refuse to accept. The reason is that display:none is often used for drop down menus, and it's easier to "display" them to allow the user to select them straight away.

Well there's your problem: hidden is not a valid value for the display property. hidden is valid for the visibility property. According to the WebAIM training that I just had, both "display: none" and "visibility: hidden" should hide content from screen readers. I don't know for certain as I have never used one.

I want to give due credit to Cyndi Rowland at WebAIM for the summary. I did not link to them in submission as their site probably would not stand up to the /. effect. I share the sentiment though. This is fantastic news, and anyone who hopes to get old should be grateful.

I'm all in favor of something that does the job better than HDMI. If you need closed captioning in the US, HDMI doesn't work for you. It omits the necessary data from the video source.

Honestly, who cares - they're both designed by people who know little about creating decent websites.

I don't know how you got away with this statement since it's just out-and-out wrong.

One of these sites exhibits nearly identical behavior with Javascript turned off (see other comments attached to this article for detail), bleeding edge technologies with graceful degradation, good semantic markup, good consistency in appearance and behavior across browsers, no detected accessibility errors, and an acceptance and embracing of open standards. It even comes extremely close to validating (those errors might even be explainable by the warning given on the page regarding "cutting edge technology"). The other? Not so close.

For some additional backup from the likes of webdesignerdepot.com and others

The Apple website is one of the best websites out there due to its ease of use, functionality and the beautiful environment that it creates.

In terms of web design, Apple.com is a very good exemple of clean semantic code and stunning graphics.

Admittedly, I'm an Apple fanboy, but come on. Even the most unabashed of Apple haters should be able to agree that there was a team of skilled and capable people behind its creation. It's by no means perfect, but there's a reason it's cited time and again as one of the best-designed sites on the Web, and it's not just because of the pretty pictures.

You know, I still don't understand why there is even such a thing as a user agent string.

Go be enlightened; there's no excuse not to be.

There's no reason not to have a user agent header, just as there's no reason not to have a 'Server' header. User agent sniffing, on the other hand, is one of the many, many, many things that we have because the internet is an amalgamation of non-standardized crap. Sites do it because they can't just send standards-compliant data, because browsers don't all render it the same. (See: box model bug.) You can't say "fuck those people", because they're the vast majority of the internet (at least, until quite recently); if you're making a public-facing website, to almost everyone who comes there, your site is broken. This is, needless to say, not an option if you want visitors.

The fundamental problem is that writing standards-breaking browsers doesn't come back to bite the authors of said browsers; they have no incentive not to do it, and in fact, if they're being anticompetitive, they have an incentive to make it even worse.

It's rather miraculous that the internet works at all.

1) The Americans With Disabilities Act (ADA) has little or nothing to do with web accessibility. (It may, pending the results of NFB v Target. But not now.) You need to check out the requirements in Section 508 if you'll be working with/for federal agencies. You need to read up on the Web Content Accessibility Guidelines (WCAG), including Joe Clark's criticism of them. I suggest starting with WebAIM and Mark Pilgrim's excellent (though dated) Dive Into Accessibility.

2) Hire a good writer and a good photographer, or an agency which has 'em. Content is king. "Punching up" the design doesn't mean a thing without that foundation.

I love being able to use Flash, but for accessability to low-speed dialup, 64bit linux (I still havent heard of Flash player working in that), and screen-readers (for the blind, etc) you would have to practically redo the site in standard html

Not true. Flash 6 and newer can integrate with screen readers or be made self-voicing (in which case a screen reader is unnecessary), and it is generally quite possible to build accessibility into flash applications. Also, in my experience a web app redesigned from HTML to flash decreases in bandwidth needed. You can get a very complicated web app with thousands or even tens of thousands of lines of code in a flash movie that's less than 100 KB because of how efficient the format is compared to HTML and javascript (bytecode-compiled).

The basic problem with flash bloat is that most flash designers are just that, designers. They're not developers, so they don't really know the tool they're using or how to use it effectively. An example of efficient flash built by developers is google finance's charting. It loads fast, it is powerful and it isn't intrusive.

Captions (or subtitles, I can't keep them straight) are a very valuable part of TV & Movies which is sorely missed when downloading video from ITMS.

Loud environments, quiet dialog, nonnative-english-speaking-viewers (or whatever the language of the video is), all are strong reasons for making captions easier to find and use, not harder. Please listen, Apple!

I have been surprised by how hard it is to view captions in the Quicktime format using the Quicktime player. The format seems to have all the necessary pieces ( I think ), but the player makes no provision for doing the right thing, in particular, the way DVD players and TVs composite the text with the video.

Instead the only option seems to be black bands with text on top of them, either via bolt-on SMIL, or via embedded data in the .MOV file.

http://newmedia.scetv.org/webaccesstc/html/capvids eg.html
http://www.webaim.org/techniques/captions/quicktim e/

So it's do-able, but so ugly and unintegrated that nobody does it. (e.g. where is the captions on/off button on the QT player?)

In what way does it fall short? Here's a decent article about Flash accessibility support, it seems reasonable to me.

Wow what a rant, that got up to 5 ( Insightful ). Way to go slashdot.

HTML/CSS/JavaScript like any technology is getting old. It wasn't designed to really be for applications. Now we have Ajax hacks and a slew of other crap to try and make it like a normal desktop app...things that flash and java applets ( yes I know applets are not that great ) just do.

Flash can be just as accesible if not more then a web page...it is all in the tools that make it accesible. Imagine if I wrote a flash app specifically for blind people...I'm guessing I could get a lot further then with just a web page.
Instead of trying to make a page accessible...i'd rather see a version of the app written specifically for blind people. It'd be better if google or other companies teamed up with another company, give them the raw content as XML and let them expose it in a way that will make it easier to access. Browser are inherently visual are they not....maybe it'd make more sense for google to try and expose the information in a way that could be converted to brail or audio easily.

Yes there are issues.
http://www.webaim.org/techniques/flash/

I'm sorry to the individuals out there that have disabilities. At the same time some content that is very hard if not impossible to make accessible can make it far easy to access for people without a disablity to use it. We need to find ways to appease both communities.

What does the poster mean by the "real Web". And they SHOULD just post PDFs on the side of their content, they are way more accesible then HTML. I mean I'm sure you could get a program to read the content of a PDF far easier then you could get it to strip out text from an html document and read it.

Browsers underline hypertext links by default. It is possible to remove the underline using Cascading Style Sheets (CSS), but this is a bad idea most of the time. Users are accustomed to seeing links underlined. They may or may not be able to figure out which text is linked if the underline convention is not used.

. It is the convention in web pages to underline links that take readers to another web source. If you underline words with the tag, readers may think you merely have a dead link. Some pages use style sheets to display links as a different color but with no underline. This is attractive, but it poses a problem for those who are color-blind.

And section 504, which applies to anyone getting federal money. http://www.webaim.org/coordination/law/us/504/

That's not entirely true: Creating Accessible Flash It takes some extra work to make Flash accessible, and not all of Flash can be made accessible, but it's still possible to make a Section 508 compatible web site using Flash.

Code after the standards not browsers, try to make the code as semantic as and always use a proper doctype, i usually recommend a sctrict-dtd.

but when choosing a doctype, you choose you should choose one that triggers the standard compliance rendering mode in the diffrent browsers. see here for a list http://www.hut.fi/~hsivonen/doctype.html

Quirksmode.org is a nice place to check out which javascript and css properties that is supported in the diffrent browsers. this css overview has been very helpfull http://www.quirksmode.org/css/contents.html

I do admire the css Zen Garden, and also David Shea's other online design work. But not so much for the pretty graphics (nice, but not of extreme interest to an artistically challenged dweeb like me) as the way it promotes usable and accessible web content. Most web pages put a priority on presentation over content. Being a technical writer, I have exactly the opposite priority. Shea is doing a good job of promoting web design techniques that let you have it both ways.

Hehe, Slashdot's not really a shining example of web accessibility, but it's a good place to ask for help none-the-less.

The first stops for help (as someone's no doubt pointed out already) should be:

Section 508

Mark Pilgrim's excellent "Dive Into Accessibility"

The W3C's web accessibility guide

The UK Disabled Rights Commission website, paying particular attention to the superb Interactive Demos (e.g. Inaccessible Website Demo).

Buy these books:

Constructing Accessible Websites

Building Accessible Websites

Oh, and a copy of Zeldman's Designing With Web Standards for good measure.

Write your pages using validating HTML or XHTML, and style the pages using CSS.

Validate your webpages using the W3C Validator and your CSS using the W3C CSS Validator. Use Watchfire's Bobby to validate your pages, and aim for AAA rating (also note that Bobby has some helpful hints when it does find errors).

Other excellent resources (in no particular order):

http://www.webstandards.org/
http://www.w3.org/WAI/References/QuickTips/
http://www.mezzoblue.com/
http://www.meyerweb.com/
http://www.simplebits.com/
http://www.whatdoiknow.org/
http://www.stopdesign.com/

Some Bobby alternatives: Cynthia Says and WAVE. There's also a Colorblind web page filter. For mozilla users, there's the Checky plug-in to manage validation services.

In case you have a problem with using something (at least partially) from HiSoftware (I know some Assistive Tech. Specialists who do), you might be interested in using the WAVE.

Here's a Google of some resources and info, as well.

Ultimately, the biggest problem I have, is that too many web designers utterly rely on these validators. The problem is, they can only check for a few different parts of the standard. For instance, an automated validator may only be able to verify compliance with maybe half of the W3C WAI (Web Accessibility Intiative)'s 65 checkpoints (that's in all 3 priorities). The other things have to be done manually, which is not really that bad if you understand what needs to be done and how to do it.

It's simply a matter of rearanging your design style slightly to accomodate some minor design principles. Unfortunately, most web designers think that a validation or repair tool will solve all of their problems. It won't.