- From: Leonard R. Kasday <kasday@acm.org>
- Date: Mon, 26 Jul 1999 17:12:09 -0400
- To: w3c-wai-er-ig@w3.org
Comments continued. As before, I've labeled comments as "minor:
signficicant", "important"
This has most text of original. I've preceded my comments with LRK:: so
you can quickly skip to them.
------------------------------------------
>Guideline 2. Don't rely on color alone.
>Checkpoint 2.1 - Ensure that all information conveyed with color is also
>available without color, for example from context or markup.
>
>Technique 2.1.A [priority 1] User notification for color use
>
>This notification will be presented to the user if the document contains
>elements that may have colors. Documents that do not contain any of these
>elements will not trigger the user notification. The following elements
>will trigger the user notification:
>
> * IMG
> * APPLET
> * OBJECT
> * SCRIPT
> * INPUT
LRK:: important: need to check text also. Give strong warning for all
colors that are not consistently associated with logical tags. For
example, if all H1 are made red, via style sheets, or use if individual
<span> tags, or by the much-despised <font> tag, that's OK. But if some H1
are red and others are blue, it raises the suspician that the color means
something.
LRK:: important: even if meaning is conveyed by something other than color
alone such as a CSS box attribute, that's not acceptable, since audio
browsers don't pick up that visual style. Furthermore, it's not even
acceptable if audio style sheets are used, until all user software supports
it.
LRK:: significant: instead of global statement, put this as a checkbox next
to each image when it is displayed along with it's ALT and LONGDESC.
That's better I think than a global statement.
>Notification: Ensure that information is not conveyed through color alone.
>For example, when asking for input from users, do not write "Please select
>an item from those listed in green." Instead, ensure that information is
>available through other style effects (e.g., a font effect) and through
>context (e.g,. comprehensive text links).
>
> ------------------------------------------------------------------------
>
>Checkpoint 2.2 - Ensure that foreground and background color combinations
>provide sufficient contrast when viewed by someone having color deficits or
>when viewed on a black and white screen.
>
>Technique 2.2.A [priority 3] Test the color attributes of the following
>elements for visibility:
>
> * BODY
> 1. BGCOLOR
> 2. TEXT
> 3. ALINK
> 4. LINK
> * TABLE
> 1. BORDERCOLOR
> 2. BGCOLOR
> 3. TD
> 4. TH
> * HR
>
>Color visibility can be determined according to the following algorithm:
>
>(This is a suggested algorithm that is still open to change.)
>
>Two colors provide good color visibility if the brightness difference and
>the color difference between the two colors are greater than a set range.
>
>Color brightness is determined by the following formula:
>((Red value X 299) + (Green value X 287) + (Blue value X 114)) / 1000
>Note: This algorithm is taken from a formula for converting RGB values to
>YIQ values. This brightness value gives a perceived brightness for a color.
>
>Color difference is determined by the following formula:
>(maximum (Red value 1, Red value 2) - minimum (Red value 1, Red value 2)) +
>(maximum (Green value 1, Green value 2) - minimum (Green value 1, Green
>value 2)) + (maximum (Blue value 1, Blue value 2) - minimum (Blue value 1,
>Blue value 2))
LRK:: important: Color difference need not be greater than a threshold.
For example, very light grey against very dark grey.
The brightness formula, ignoring color, is a good start. Be prepared to
check if data fits better if brightness is raised to power first. The
texbooks say that isn't perfect but may be good enough for our practical
purposes, given all the other uncertainties.
Another simple formula: is just difference in the green components, or
better, green components raised to a power. This should be checked against
people with protonopia (reduced sensitivity to red, a type of color
blindness) and people who lose blue sensitivity as they age.
>
>The rage for color brightness difference is 125. The range for color
>difference is 500.
>
>Language for poor color contrast between the foreground and background
>colors: Poor visibility between text and background colors.
>
>Link to test files for this technique.
>
> ------------------------------------------------------------------------
>
>Guideline 3. Use markup and style sheets and do so properly
>
>Checkpoint 3.1 - When an appropriate markup language exists, use markup
>rather than images to convey information
>
>Technique 3.1.A [priority 2] User notification for appropriate markup
>language
>
>This technique describes notifications presented to the user for
>checkpoints that can not be machine tested.
>
>BODY elements will generate the following user notification: When an
>appropriate markup language exists, use markup rather than images to convey
>information. For example, use MathML to mark up mathematical equations, and
>style sheets to format text and control layout.
LRK:: significant: add checkbox to display of images, e.g. "is this a math
equation"
LRK:: important: do we _really_ want people to use mathML before any
browsers support it? I recommend using it as an object with the image
version nested within in case mathml not supported.
>
> ------------------------------------------------------------------------
>
>Checkpoint 3.2 - Create documents that validate to published formal
>grammars
>
>Technique 3.2.A [priority 2] Check document for public text identifier
>
> * The first line of the document must be a valid public text identifier
> if the document being validated is an HTML document.
> * A valid public test identifier is... (Haven't got precise definition.
> Anybody know for sure?)
LRK:: signficicant: DOCTYPE is specified at
http://www.w3.org/TR/REC-html40-971218/sgml/dtd.html
> * The document is an HTML document if there is an HTML element near the
> start of the document and there is an HTML end element as the last
> non-whitespace text in the document.
LRK:: important: run through w3c validator
LRK:: minor: <HTML> tag reqt is redundant with checking overall syntax.
>
>Language for missing public text identifier: Missing language identifier
>for this document.
>
>Link to test file for this technique.
>
> ------------------------------------------------------------------------
>
>Checkpoint 3.3 - Use style sheets to control layout and presentation
>
>Technique 3.3.A [priority 2] Check document for use of style sheets. Notify
>user if they are not used.
>
>Check document for the presence of STYLE elements. If there are no STYLE
>elements, notify the user with this text:
>
>Use style sheets to control layout and presentation. For example, use the
>CSS 'font' property instead of the HTML FONT element to control font styles
LRK:: minor: make this less of a command until most browsers implement CSS,
and do so correctly, especially for layout.
> ------------------------------------------------------------------------
>
>Checkpoint 3.4 - Use relative rather than absolute units in markup language
>attribute values and style sheet property values
>
>Technique 3.4.A [priority 2] Check STYLE attributes for relative or
>absolute units.
>
>[Needs work]
>
> ------------------------------------------------------------------------
>
>Checkpoint 3.5 - Use header elements to convey document structure and use
>them according to specification
>
>Technique 3.5.A [priority 2] Check document for header nesting
>
> * Header elements (H1-H6) should be checked to ensure they are nested
> according to the following rules
> 1. The first header element in the document must be H1
> 2. There must be only one H1 element in the document
LRK:: significant: Really? Only one H1? Not mentioned in guidelines or
technique http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#document-headers
> 3. Header levels must not increase by more than 1 level. Example: H2
> following H1 is good. H3 following H1 is bad.
> 4. Header elements can decrease by any level. Example: H2 following
> H5 is OK.
>
>Language for improper header nesting: Improper header nesting:
>
> 1. First header in the document must be an H1.
> 2. There must be only one H1 in a document.
> 3. Header levels must not increase by more than one level per heading.
>
>Link to test file for this technique.
>
>Technique 3.5.B [priority 2] Check document for missing header markup
>
> * Text elements within a paragraph should be checked to see if they
> should be headings. Potential headings can be identified by:
> 1. Text elements occur within a paragraph and...
> 2. The paragraph is less than 10 words and...
> 3. The paragraph contains only text items or formatting elements
> and...
> 4. All text in the paragraph is formatted as bold and/or italics
> and/or underline.
LRK:: significant: if text is simply made larger that raises suspician it's
a heading.
LRK:: minor: I might quibble with how many words in a paragraph consitute a
heading.
LRK:: significant: heading can be first few words of paragraph. If it's
bold, italic, or big it's suspicious. Automatical HTML translation of
things like Word docs can to this.
LRK:: important: a big image at the beginning of tha page is probably a
heading.
>
>If a potential header is identified, notify the user with this language:
>Document text has been identified that could possibly be a header. Is this
>text used as a header: (potential header text)?
>
>Link to test file for this technique.
>
>Technique 3.5.C [priority 2] User notification of improper header use
>
>This technique describes notifications presented to the user for
>checkpoints that can not be machine tested.
>
>Header elements (H1- H6) will generate the following user notification:
>Header elements (H1 - H6) should be used to define headers and should not
>be used for formatting text.
>
> ------------------------------------------------------------------------
>
>Checkpoint 3.6 - Mark up lists and list items properly
>
>(I think the idea behind this checkpoint is that ordered lists should be
>used for nested lists and that each item should contain information about
>the nesting. Example list items: 1, 1.2, 1.2, 1.3. But how can this be
>done? The following example shows that browsers don't display nested list
>numbers very well.)
>
>The nested list:
>
> <OL>
><LI>item 1<OL>
><LI>1 Item 1.1</LI>
><LI>2 Item 1.2</LI>
><LI>3 Item 1.3</LI>
></OL>
></LI>
><LI>item 2</LI>
></OL>
>
>Displays as:
>
> 1. item 1
> 1. 1 Item 1.1
> 2. 2 Item 1.2
> 3. 3 Item 1.3
> 2. item 2
>
>Link to discussion on this technique.
LRK:: important: check for lists disguised as tables. E.g. consecutive
items all starting with same little image.
>
> ------------------------------------------------------------------------
>
>Checkpoint 3.7 - Mark up quotations. Do not use quotation markup for
>formatting effects such as indentation
>
>Technique 3.7.A [priority 2] Check document for missing quote markup
>
> * Text elements should be checked to find text that should be marked as
> Q or BLOCKQUOTE. Potential quotes can be identified by:
> 1. Any text that is enclosed by quote marks (" " or ' ').
>
>If a potential quote is found, the user should be notified with the
>following language: The following text may need to be marked using Q or
>BLOCKQUOTE: (potential quote text).
LRK:: signficant: I don't think block quotes should be enclosed by
quotation marks, stylewise. Any English majors in the audience? Hmmm.
What's convention in other language?
>
>Link to test file for this technique.
>
>Technique 3.7.B [priority 2] Check Q and BLOCKQUOTE to ensure they are used
>properly
>
> * Q and BLOCKQUOTE elements should be checked to ensure they enclose the
> correct type of quote.
> * Inline quotes (marked with Q) have at least one word in front of, or
> behind, the quote text and are less than 10 words
> * Long quotes (marked with BLOCKQUOTE) are greater than 10 words.
>
>If a block of text is marked as BLOCKQUOTE when it should be marked as Q,
>the user should be notified with the following language: This text should
>be marked as Q not BLOCKQUOTE: (quote text).
>
>If a block of text is marked as Q when it should be marked as BLOCKQUOTE,
>the user should be notified with the following language: This text should
>be marked as BLOCKQUOTE not Q: (quote text).
>
>Link to test file for this technique.
>
>Technique 3.7.C [priority 2] User notification of improper BLOCKQUOTE or Q
>use
>
>Q or BLOCKQUOTE elements will generate the following notification:
>BLOCKQUOTE or Q elements should be used to define quotes and should not be
>used for formatting text.
>
> ------------------------------------------------------------------------
>
>Guideline 4. Clarify natural language usage
>
>Checkpoint 4.1 - Clearly identify changes in the natural language of a
>document's text and any text equivalents (e.g., captions)
>
>Link to discussion on this technique.
LRK:: minor: there are automatic means for guessing at languages which
could be applied to check if language changes. Don't know if it's worth
the effort compared to other checks. But then again, I'm pretty
Anglo-centric.
>
> ------------------------------------------------------------------------
>
>Checkpoint 4.2 - Specify the expansion of each abbreviation or acronym in a
>document where it first occurs
>
>Link to discussion on this technique.
LRK:: minor: mark first time each used and look for words in parens after,
e.g.
The W3C (World Wide Web Consortium)
It's also OK to have
World Wide Web Consortium (W3C)
>
-------
Leonard R. Kasday, Ph.D.
Universal Design Engineer, Institute on Disabilities/UAP, and
Adjunct Professor, Electrical Engineering
Temple University
Ritter Hall Annex, Room 423, Philadelphia, PA 19122
kasday@acm.org
(215} 204-2247 (voice)
(800) 750-7428 (TTY)
Received on Monday, 26 July 1999 17:09:35 UTC