Re: Web Accessibility Checklist was Re: Please review my site

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

On Wed, 27 Jun 2007 00:30:04 -0700, Chaddy2222

Quoted text here. Click to load it

I've just noticed that the WCAG Samurai (which includes Joe Clark) have
recently published their errata to the WCAG guidelines /

This is an introduction to the errata (corrections) for the Web Content
Accessibility Guidelines 1.0 (WCAG 1). The errata are published by, and
can be attributed to, the WCAG Samurai, an independent group of
developers convened in 2006. We delivered these errata on 2007.06.07.

I just love this document, particularly the no-nonsense tone of the
intro  8-)

Re: Web Accessibility Checklist was Re: Please review my site

Andy Dingley wrote:
Quoted text here. Click to load it
Hmmm, yes I had a read of that. It sounds good although one thing I am
not sure of is how exactly they want developers to make javascript and
such content accessible without placeing items in a <noscript> tag, as
screen reading software still does not do JS very well. Unless it
could be done through some kind of server side method?.
Regards Chad.

Re: Web Accessibility Checklist was Re: Please review my site


Quoted text here. Click to load it

BTW Chad I love the results of your recent site makeover: good solid
structure and colours that together allow the message of the page to
be delivered.


Andrew's Corner

Re: Web Accessibility Checklist was Re: Please review my site


Quoted text here. Click to load it

<noscript> never really worked, was never really appropriate, and was
almost never used correctly.

The basic rule for JavaScript on Web 1.0 pages is that it should never
be necessary. use it for rollovers, decoration, gimmickery etc. but
lay off using it for the core function. In these cases, you don't need
to dupe it into <noscript> at all.

There are very few cases where JavaScript can be replaced by
<noscript>. If you're using client-side JavaScript to generate
content, then it's usually simply better to do this server-side
anyway. You might (in WCAG world) have to do just this to populate the
<noscript> that you'd be better off avoiding the need for altogether.

Web 2.0 is different.  If you're AJAXing your content into place with
asynch loads, then there's just no way to replace that with any sort
of static notice in a <noscript>. The fix here is to fall back to a
Web 1.0 implementation instead, with lots of <form>s, page submissions
and round-tripping the whole page back to the server.  This gets
really messy to try and cover both patterns on a single page, so
you're often better doing it as two separates.

There's never a need to make any _page_ accessible -- it's always an
alternative to offer an accessible page _in_addition_. Although good
CSS techniques make this costly process unneccessary for general
design work, it can be a reasonable approach when you're doing AJAX
and similar work.

If you're going this deeply into things, you really need to be using
an MVC pattern too. You'll maybe build it without, but you wouldn't
want to maintain it afterwards.

Re: Web Accessibility Checklist was Re: Please review my site

Quoted text here. Click to load it
Well yes, I think that is the type of thing I was thinking of,
personally I would just do the lot server side, considering the
availibility of band width now a days it's really not a big deal to
just let the server deal with processing form data etc.

Quoted text here. Click to load it
That makes a lot of sence realy. It's all the more reason for useing
server side technology instead of doing thing client side and needing
too then code stuff on the server anyway just in case.

Quoted text here. Click to load it
I had too google some of what you ment in that previous sentence but I
think I get the idea.
Regards Chad.

Re: Web Accessibility Checklist was Re: Please review my site

On Wed, 27 Jun 2007 23:13:51 +0100

Quoted text here. Click to load it

It's a shame they show such deep tunnel-vision, and make leaps
of illogic from "XYZ is often abused" (or even "XYZ might be
suboptimal", in the case of serverside imagemaps) to "XYZ is banned".

Nick Kew

Application Development with Apache - the Apache Modules Book /

Re: Web Accessibility Checklist was Re: Please review my site

Quoted text here. Click to load it

"Ignore all references to °»non-visual displays°… or °»monochrome
displays.°… Web accessibility is about people with disabilities, not
their equipment. A °»display°… is not a person and does not need

This seems to me to be a *very* narrow view to take, too. To me,
device-independence of content is an important part of web
accessibility even if the goal is solely about people, and even if the
goal is solely about people, it should be about accommodating people's
specific requirements, and those requirements may not be ones
recognised as disabilities.

Example 1: I currently use Firefox and Lynx as my most common two
browsers. If I were to suffer from a motor disability that prevented
me from using a mouse effectively, I'd drop Firefox and keep
Lynx. Despite my vision remaining good, I still benefit very strongly
from good practice with colours in this case, solely because of the
display technology I would use.

Example 2: When I'm coding, I find (and I freely admit this is
probably very unusual) I'm much more efficient using lots of text
consoles and using Alt-n to switch between them, than I am with a
windowed environment (and especially not with the slow switching
between X and console). I therefore use text browsers rather a lot
when coding. I agree, the display is not me, but that doesn't mean
that I don't benefit considerably from sites that are accessible on
that display.

Example 3: If I only have a monochrome printer, and find it easier to
read pages printed (and perhaps expanded) than on screen.

Now, as it happens, in the specific case of colours, if you design it
so that it works for people with the particular disabilities
mentioned, it also works fine for people with different display
technology, so it's not a major problem. On the other hand, it seems
to be a worrying principle to set out.

Also, in their (correct) removal of most of the Priority 3 guidelines,
they seem to have liked the simplicity of getting rid of all of them
(to the level of MUST NOT) over making sense. For example: "13.9
Provide information about document collections..." is now marked with
a terse "Ignore" despite it being a generally good idea if you happen
to have document collections. Given that they say you must not comply
or attempt to comply with any Priority 3 guideline, this means that if
you do have a document collection, you must go out of your way to
avoid giving information about it, or fail to meet WCAG1+S

"13.6 Group related links ..." is ignored on the grounds that "Not all
sites or pages have related links" (which seems an incredible
non-sequitur: not all pages have non-text content, so should 1.1 also
be ignored?) and "[no element with relevant semantics]" (which I'd
have thought <ul> made a reasonable go at in many cases)

Similarly, 9.4's errata "Do not attempt to create your own tab order"
seems to be based on a misunderstanding (albeit a very common one) of
what 9.4 "Create a logical tab order..." meant in the first place. The
common interpretation seems to be 'tabindex', but it could just as
easily refer to placing the elements into the document in an order
that gave a sensible tab order without the need for tabindex -
something that remains fairly important.

I'd also have liked to see some attempt to address the box ticking
nature of "compliance with WCAG1.0" rather than just replacing some of
the boxes.


Re: Web Accessibility Checklist was Re: Please review my site

Scripsit Andy Dingley:

Quoted text here. Click to load it

Initially, I had high expectations, but I found no other author name but Joe
Clark, and that's ominous: an anonymous group issuing something that
purports to be authoritative. The word "errata" is frightening, too: that
word has long been abused by the W3C as a pseudo-term for sloppily written
documents that have an undefined status.

So I tuned down my expectations and wasn't really surprised at seeing very
wrong moves like banning all layout tables.

Jukka K. Korpela ("Yucca")

Site Timeline