W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2004

Comments on draft. part 1.

From: Mirabella, Mathew J <Mathew.Mirabella@team.telstra.com>
Date: Fri, 12 Mar 2004 10:28:19 +1100
Message-ID: <73388857A695D31197EF00508B08F2980FEEB9C0@ntmsg0131.corpmail.telstra.com.au>
To: "w3c-wai-gl list" <w3c-wai-gl@w3.org>

Hi all.

Apologies for not being at meetings recently.  Here are some comments I have on the current working draft.  They are split up into each section (heading) in the draft.  This email gives my comments for the first part of the document up until where the guidelines begin.

Status of this document.

Paragraph 2
Spelling / typo error.
	...to show how more generalized (less HTML-specific) WCAG guielines might read. This draft is not yet based on consensus of the WCAG Working Group...

3 - Bottom layer - Technology-specific application information
is there any direction to incorporate mathML, or WAP in this list?  (I understand that it depends on who can contribute to this etc.).  There are a number of mobile handsets with adaptive technology availabel (i.e. nokia phones with talx) so accessibility of content in WAP may be important.
Also, are we going to include anything like PDF or Flash in this set.  (I understand that these are not w3c technologies, but can we get techniques for these or at least link to existing good ones).

The definitions of success criteria

I understand and appreciate the notion of having level 1 = does not specify how information is presented and higher levels = may require authors to present information in particular ways.  But what if there is a particular issue in which the way content is presented lies at the heart of whether that content is accessible to a large number of people?

For example, the colour contrast issue
Guideline 1.4:  Level 1:  Any text that is presented over a background is electronically available so that it could be re-presented in a form that allows the text to be distinguished from the background.

Making the text "electronically available" as opposed to "make the text contrast with the background in the default presentation", is one of the things that distinguishes level 1 from level 2 here, as in level 1 does not "require" changes to the presentation, but merely requires that the text is available to someone who can get to it in other ways, almost independent of the issue of whether or not contrast is sufficient.

I have a slight problem with a level 1 criteria in the realm of colour contrast that does not actually require colour contrast at all.  It is almost like a completely separate issue... "make sure that text is electronically available", which, under the interpretation of some content authors, might not have anything to do with contrast.  They may tackle level 1 without ever thinking about contrast.

There are a very large number of users with vision-impairment (either colour related or not) who would genuinely need good contrast to perceive the content.  These users may not use screen readers or other electronic forms of obtaining text from the page, and may choose to use GUI browsers in the usual way (albeit with enlargers etc).  Are we going to allow content developers to create a site that is rich in subtle colour differences, poor contrast, almost impossible for these users to perceive, and allow the content author to claim level 1 against this guideline just because the content is text that could be cut and pasted from the browser if the user knows how? (I know this has been discussed a little before).

Are we expecting that users who might have issues with colour will set their user agent or user style sheet to always show black on white or white on black just in case there are contrast issues in the default presentation of some content?  DO we expect users to be readily able to determine (perceive) on visiting some content, that there is sufficient contrast and they will now need to invoke their special settings to perceive the content.  There are maybe issues of the perception of the perceivability of the content, not just perception of the content itself.  Where does responsibility lie for this.

This is especially important when you consider that there are also many people with cognitive or intellectual disabilities who may not know how to "copy out" the text from a page, let alone be able to switch on and off browser settings and user style sheets.  This is not to mention that many people may not even know that they might have to copy out the text or change settings to perceive the content.

So have we determined if there are not scenarios where default presentation is very much a part of the core of the particular accessibility issue in question?  In common sense terms, it seems important to ensure that level 1 deals with the core, level 2 deals with everything that is important and level 3 deals with everything else (including the "nice to haves").... Or something along these lines.

Claiming conformance.

There seems to be an issue of how developers can make claims about conformance to more than the particular A, AA and AAA levels in a way that demonstrates what they have complied to.

One suggestion:
A = all level 1
A+nnnn = all level 1 and some others
AA = all level 1 an level 2
AA+nnnn = all level 1 and 2 and some others
AAA = All level 1, 2 and 3
where nnnn refers to a four digit code saying how many of the extra guidelines are conformed to, with the first digit showing the number of extra "perceivable" guidelines, the second digit showing the number of "operable", the third showing the number of "understandable" and the fourth giving the number of "robust" guidelines met at the higher levels.

Alternative suggestion
Use the A, AA and AAA to prefix a string that shows the level of conformance.  The string would contain comma-separated values showing the specific guideline numbers and what level of success criteria has been met.
A,1.4:2,2.1:3 means level A has been achieved, but in addition, 1.4 has been met at level 2, and 2.1 at level 3.

could use Dublin Core Meta data to show this information in some way.
Received on Thursday, 11 March 2004 18:28:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:55 UTC