- From: Daniel Dardailler <danield@w3.org>
- Date: Fri, 07 Nov 1997 15:31:49 +0100
- To: w3c-wai-gl@w3.org
General comments (maybe I should rate them with stars too :-)
- I think the TOC at the beginning should point only to local anchors
in the document, rather then a mix of both internals and externals
(like quick guides). The pointers to external document should be
gathered in the format section.
- furthermore, I think the section
Profiles of users with disabilities
and many others sections (tutorials, etc, see comments below) should
on in separate documents.
- I don't like the word TOMORROW, as it has a connotation "to be
done in the future, shouldn't care today", where in fact, people
should start changing their markup today with the result taking effect
in the future (much like seeding)
I also prefer CURRENT over TODAY, but not as strongly.
I'd like to have a keyword for CURRENT+NEW: ALWAYS.
So I'd prefer
CURRENT
NEW
ALWAYS
- it would be better if not only the recommendations, but also the
example, the tips and the intro to the issues, where rated as TODAY
or NEW or ALWAYS.
- Recommendations for user agent (browser) designers
Recommendations for assistive technology designers
Suggestions for users
Throughout the document, there are sections for browser and tools and
users. I strongly think this should go in their own book. I agree
there are relationship between the different guidelines, but since
the audience is different, I don't see why they should be
bundled. Our primary focus should be to make each document very
simple to comprehend.
The goal is also to make each guideline document easier to manage.
I have only reviewed the page author part.
- At some point, we need to go over the WAI archives (IG/HC) and
gather all the cases where we mentioned "this should be in the
Markup guidelines, not in the HTML format itself"
- I'd like to have the quick and check list in some sort of
prioritized order, not just the header of the guideline doc. Some
kind of top 5 and then the rest.
Onto the documents itself (my comments start on column 1)
Screen Reader
A software program that runs on a computer and reads the contents
of the screen aloud to a user. Used primarily by individuals who
are blind. Can only read text that is printed, not painted, to the
screen.
I think we should try to explain better somewhere and make the
difference here between screen readers that are Markup aware and those
who operates on a formatted output.
5. [Place holder for "HTML and URLs"]
6. [Place holder for "HTML Document Character Set"]
7. [Place holder for "Basic HTML data types"]
8. The global structure of an HTML document
The HEAD and BODY of a document
I think an HTML tutorial as a separate document (or in the annex) is a
better idea.
[2 star.] Use the TITLE element in the HEAD of each document.
[TODAY & TOMORROW]
For example, <HTML><HEAD>...<TITLE>Version 8 of the Unified Web
Accessibility Guidelines</TITLE>...</HEAD>...
This is mandatody since HTML3.2. Every HEAD must have a TITLE.
But I guess the more relevant question, rather that saying it's not
valid if not there, is to look on the web today for the existing use
of TITLE. If a large manjority of HTML authors are already using it,
then we shouldn't mention it here (again, to save bandwidth).
[2 star.] Use the full text of dates. [TODAY & TOMORROW]
For example, February 28, 1996. Even if the user speaks a
different language, the date can be easily interpreted.
I think this is in the range: make sense, use good design. I'm not
sure we want to point at all the issues of that kind. I understand the
problem is always worse for accessibility, so I think it's a matter of
priority, i.e. how much worse is the issue. This one, I think is low.
1. [3 star.]- Use style sheets: [TOMORROW]
Related to my wanting NEW instead of TOMORROW, this is the kind of
thing I'm worry about: Use Style sheet tomorrow (not today :-)
CSS is in IE since August 96 and in NS 4 this year.
It's not tomorrow.
2. [3 star.] - Use proportional and logical styles rather than physical
markups [TODAY & TOMORROW]
Logical: DFN, EM, CITE, CODE, KBD, SAMP, STRONG, VAR, H1, H2, etc.
Proportional: size=+1 or size=-4
The HTML FONT tag is deprecated altogether in HTML 4 so we should just
point at CSS rather than saying proportional size is good (even if
it's better than physical, which I agree).
10.3 Punctuation, symbols and ASCII art
Issue: Screen reading software often ignores or reads each name
for punctuation that has been used to make an emoticon or ASCII
art. For example, the smiley emoticon :-) would either be ignored
or read as "colon dash close parentheses."
"colon dash close parentheses"
That's the way I parse it myself :-)
[2 star.] Use a graphic with alt-text to avoid uncommon
typographic characters or constructions such as emoticons, arrows
consisting of dashes and greater than signs -->, etc.. [TODAY &
TOMORROW]
I think the point about emoticons is only CURRENT and in the NEW
agents, there should be enough intelligence to recognize a predefined
list of smileys.
1. [3 star.] Use the appropriate list markup for lists and list items.
[TODAY & TOMORROW]
2. This is an ongoing topic of discussion, stay tuned for developments.
I mentioned that on the list: CSS with img in CSS or img in HTML
depending on the semantics conveyed by the img.
12.1 Comprehension and navigation of table elements
Issue 1: Newspaper columns. Tables are often used to layout pages
of text in newspaper columns. Screen Readers read all the way
across the page reading sentences on the same row from different
columns as one sentence.
In the intro sections, like here, I would like to see mentioned that
"dumb" screen reader operates like that, not markup aware products.
1. [3 star.] Avoid using tables to arrange text documents in columns or
otherwise layout a page. Instead use style sheets. [TOMORROW]
This is called positioning and it's in CSS2.
Testing tips
1. To predict how a screen reader might read your table, hold a piece of
paper up to your monitor and read completely across the screen. As you
slide the paper down the monitor, read aloud to another person the text
that appears above the line the paper creates (without pausing for
gaps). Does what they hear make sense?
This is clearly a TODAY example.
2. Another method to predict how a screen reader will interpret your page
is to save it as text only (available in the "File" menu in most
browsers) then open it with a word processing program.
That's strongly dependant on the tool being used.
Maybe we should point to a "lynxer" service and use that as our
acceptance criteria for linearization of HTML.
[3 star.] Include enough words in the link phrase that it will
make sense when read out of context. [TODAY & TOMORROW]
A person should be able to read a list of just the links from a
page and be able to select one without finding what context it was
used in. For example: "click here, click here, click here" would
not allow a person to select a link without reading the context.
Something more meaningful would be: "download the full version of
this document in ASCII text, download the full version zipped with
gzip, view the full version in HTML."
On link, using TITLE on A should be a NEW way of conveying the
semantics of the link, as an alternative of people really wanting to
use "Click here" as the link text.
13.4 Methods for linking to alternate pages
I have an overall issue about text alternate page, that I will bring
up here, but it applies to most mention of providing a text-only
version.
In short: it's a possible CURRENT practice but we shouldn't promote it
for the future, rather we should promote one single source and
multiple SS.
Recommendations for page authors
1. [4 star.]Include alt-text for all images and image maps. [TODAY &
TOMORROW]
All images should have alt-text that describes the function of the
graphic. Examples: "XYZ Logo," "Section Title: Banana Products," "Graph
of population versus age," or "Search Button."
One important message is that if ALT on IMG is **** then ALT on IMG
that are in A is ******.
Also I don't see the guideline for ALT text for decoration elements
(should it be ALT="" or ALT="red flower" ?)
The alt attribute is mandatory for the AREA and IMG elements, but
should also be used for APPLET, and INPUT.
ALT for APPLET is TODAY while content for OBJECT is NEW.
2. [4 star.] Use the title attribute of the A element to provide more
information about the image/link for links to images where alt-text is
not possible (when an image is linked to from a frame). [TODAY &
TOMORROW]
For example: <A href="http://www.server.com/images/pic3.gif" title="Two
photos of the happy couple from their earlier years.">Elementary</A>
We need to be more detailed on the relationship TITLE/ALT in the A/IMG
context (related to the recent TOOLTIP discussion on the list).
3. [4 star.]Provide a link to a longer description. (This is especially
critical information in charts, tables, and diagrams.) [TODAY &
TOMORROW]
D-link is CURRENT, LONGDESC is NEW, so we need two entries here.
5. [4 star.] Use client-side instead of server-side image maps [TODAY &
TOMORROW]
Image map should be refined using
- ALWAYS: use client side
- CURRENT: provide ALT for AREA (when using MAP)
- CURRENT: provide text right after server side if no other option
- NEW: use OBJECT integrated desc+A
1. Use the alt attribute of the AREA tag (with the IMAGE, MAP and
AREA tags)
<IMG src="welcome.gif" alt="Image map of areas in the library"
usemap="#map1">
<MAP name="map1">
<AREA coords="0,0,30,30" href="reference.html" alt="Reference">
<AREA coords="34,34,100,100" href="media.html" alt="Audio Visual
lab">
</MAP>
2. Use the alt attribute of the AREA tag (with the OBJECT, MAP and
AREA tags)
<OBJECT data="welcome.gif" usemap="#map1">
alt="Image map of areas in the library" </OBJECT>
<MAP name="map1">
<AREA coords="0,0,30,30" href="reference.html" alt="Reference">
<AREA coords="34,34,100,100" href="media.html" alt="Audio Visual
lab">
</MAP>
3. Use the title attribute of the A tag (with the OBJECT and SHAPES
tags)
<OBJECT data="welcome.gif" shapes>
Areas in the library
<A coord="0,0,30,30" href="reference.html" title="Reference">
<A coords="34,34,100,100" href="media.html" title="Audio Visual
lab">
</OBJECT>
Maybe this should go into a tips section, to make the recommendation
itself short.
3. [4 star.] HOWEVER, do not require the use of style sheets. If your
page is unusable when style sheets are turned off, provide an alternate
page which doesn't use them.
We should recommend that this should never be the case.
1. [4 star.] Provide a NOFRAME option [TODAY & TOMORROW]
Once the screen reader can intelligently parse FRAME, NOFRAME will not
be an issue anymore, so this is TODAY only.
20. [Place holder for "SGML reference information for HTML"]
21. [Place holder for "SGML Declaration"]
22. [Place holder for "Document Type Definition']
23. [Place holder for "Transitional Document Type Definition']
24. [Place holder for "Frameset Document Type Definition"]
25. [Place holder for "Named character entities"]
Better in a separate document I think.
Received on Friday, 7 November 1997 09:32:09 UTC