Re: Template for Accessible Web Page

Hi David,

You've outlined a number of issues, some of which I can agree with. One of
them is a critical flaw. I don't think the site in question is exemplary of
modern accessible design practices, and for that reason I've asked that it
be updated or removed from the site.

However, I can't help but notice that your concerns are mostly about
validation, and that your testing tool is the text browser Lynx, and not any
real-world assistive technology. There's more to it than semantics and
validation, and the templates that I've tested, with the exceptions noted
below, work fine with assistive technology.

On 3/24/08 11:03 AM, "David Dorward" <david@dorward.me.uk> wrote:
> * XHTML in a world with Internet Explorer

[MM] Not an accessibility issue.

> * Transitional (when the differences between Transitional and Strict
> are tiny other that the addition of things which violate WCAG)

[MM] This also has nothing to do with accessibility.

> * No XML prolog (required if not UTF-8) but a claim that it is
> ISO-8859-1

[MM] This is required for standards mode in IE 6.

> * Navigation implemented as a select element ... and dependant on
> JavaScript

[MM] Yes, this is an issue, and I will see that it is resolved.

> * JavaScript commented out. This was encouraged in HTML 4.x to
> protect pre-HTML 3.2. In XML, however, it is an actual comment. This
> causes the document to depend on being served as text/html rather
> then application/xhtml+xml (which the specification says it SHOULD be
> served as).

[MM] Not an issue since, as you mentioned, it doesn't have the XML prolog,
and is XHTML Transitional.

> * Lack of label elements

[MM] Yes, this is also an issue.

> * Invalid

[MM] Yes, there are some bullets missing alt text, and that shouldn't be,
though in reality it doesn't affect the overall accessibility. But do
superfluous attributes here and there really make a document inaccessible?
Be careful of your answer:

http://validator.w3.org/check?uri=http%3A%2F%2Fdorward.me.uk%2F

> * ASCII art used to separate list items ... no li elements in
> evidence on some lists.

[MM] Now you're really overreaching. A pipe is not "ASCII art". As most of
us know by now, printable characters between adjacent links were specified
in WCAG 1 checkpoint 10.5.

> * ALL CAPS used instead of CSS. IIRC, this causes some screen readers
> to spell the word out as an abbreviation.

[MM] Yes, also an issue, but mostly an inconvenience. And in JAWS 8, at
least, it does read correctly.

-
m

Received on Monday, 24 March 2008 19:16:26 UTC