- From: Daniel Dardailler <danield@w3.org>
- Date: Mon, 08 Dec 1997 18:45:52 +0100
- To: w3c-wai-gl@w3.org
Comments (marked with DD::) on the content of the Markup guidelines.
> Style Sheets - Controlling the presentation of an HTML document
>
> 1. [Required]
> Use style sheets to position text and objects within pages, rather
> than physically marking up text and graphics (e.g. <B> or the "align"
> attribute of <IMG>) (However, continue to use logical elements such as
> STRONG, H1, etc. to provide semantic coding within the body of the
> page) [New]
>
> Use style sheets rather than:
> o converting text to images or alternative text file formats (such
> as PDF)
> o using tables or PRE elements to layout pages
> o using proprietary extensions
> o using "invisible" images to layout pages
> o writing a program to accomplish something that is possible with
> style sheets or plain HTML
DD:: Reality check.
I think it is not reasonnable to mark as "required" not using table to
layout things, and to put it in the same bullet list as horrible
things like converting text to image or using 1pixel gif.
CSS2 positioning will provide better support for absolute position of
boxes on page and there is already some floating properties in CSS1,
but we're still far from the implicit-rescaling and the simple layout
model provided by table rows and columns. Plus there are thousands of
such tables out already and I don't see them moving to any kind of
positioning anytime soon (W3C being on my top list).
I would argue for talking about TABLE in the table section only, while
exposing the details of making TABLE (even used for layout)
accessible. More comments there.
> 4. [New] Create a descriptive paragraph within the <OBJECT> element
> that includes the links (using the OBJECT and A elements)
> <OBJECT data="welcome.gif" shapes>
> There are several areas in the library including <A
> coord="0,0,30,30" href="reference.html">Reference</A> and <A
> coords="34,34,100,100" href="media.html"> the Audio Visual
> Lab</A>. More text can follow or precede.
> </OBJECT>
DD:: shapes on OBJECT is not supported anymore, instead, the content model
for MAP has been extended to support the same "integrated description"
capability.
e.g.
<OBJECT data=welcome.gif usemap=#map1>
Sensitive map for the library...
</OBJECT>
<MAP name=map1>
There are several areas in the library including <A
coord="0,0,30,30" href="reference.html">Reference</A> and <A
coords="34,34,100,100" href="media.html"> the Audio Visual
Lab</A>. More text can follow or precede.
</MAP>
> 5. [Recommended]
> Provide descriptive titles for all images used as links.
> Use the "title" attribute of the <A> element to provide more
> information about images used as links (usually a graphical button).
> For example, <A HREF="home.html" title="XYZ company home page"><IMG
> SRC="logo.gif" alt="XYZ logo"></A>
DD:: I'd say "Provide descriptive +link+ titles for all images used as links"
and I'd make this one a required [New]
What's missing is the guidelines for decorative image: use "", or
"deco", or something else, we should be explicit about ALT for
decoration since this is something everybody is asking about.
> 3. [Required]
> Provide alternative text for all applets.
> 1. [Interim] <APPLET code="Hello.class" width="500" height="500"
> alt="Java applet that prints a message">Hello World!</APPLET>
> 2. [New] <OBJECT classid="Hello.class" width="500" height="500"
> title="Java Applet that prints a message">Hello World!</OBJECT>
DD:: We should probably advise people to use the OBJECT element and not
APPLET.
> 7. [Recommended]
> For applets embedded with the <OBJECT> element, provide alternative,
> accessible presentations of information within the <OBJECT> element
> body. [New]
> In HTML4.0 the <APPLET> element has been replaced by the <OBJECT>
> element.
DD:: Maybe here it should say ".. use it instead".
> 3. [Recommended]
> Avoid using the BLINK and MARQUEE elements. [Interim]
> Use another method to draw attention to text such as text size or
> color.
DD:: I'd make this one a required.
> * To get a better understanding of what a screen reader would present to
> a user, do not load the images on a page when viewing with a graphical
> browser or use a text-based browser such as Lynx.
DD:: At this point, we'll provide a link to a lynx-it kind of page.
> Lists and Outlining
>
DD:: We need to talk about list that use image as bullet here.
Two examples:
First, the image is purely decorative and can be expressed solely in
CSS.
UL { list-style: url(button.png) }
<UL>
<LI> Audrey
<LI> Laurie
<LI> Alice
</UL>
Second, the image conveys some information and has to appear in the
markup, not in the style (and the default style list visual is turned
off)
UL { list-style: none }
<UL>
<LI> <IMG SRC=browneye.png ALT="Brown eye drawing"> Audrey
<LI> <IMG SRC=greeneye.png ALT="Green eye drawing">Laurie
<LI> <IMG SRC=blueeye.png ALT="Blue eye drawing">Alice
</UL>
> 1. [Required]
> Provide semantic tagging of table and cell data. [New]
> Future browsers and assistive technologies will be able to
> automatically translate table data into linear fashions if tables are
> tagged appropriately. Since the debate is ongoing about what provisions
> will be supported in HTML 4.0 this item will be revisited when the
> specification has solidified.
DD:: It's now solidified, so we could point at example of using SCOPE,
AXIS, etc. Al has some that he circulated in Austin.
> 2. [Required]
> Avoid using tables or <PRE> elements to arrange text documents in
> columns or otherwise layout a page. (Use style sheets to position
> graphics and text [New]).
DD:: I think it's OK to say that here after we've talked about TABLE markup.
I'd make this one a Recommended though, just to be realistic.
I think there are 3 kinds of table (not 2 as previously mentioned by
others): the first kind if real "table", showing real table data
(expense report, travel schedule, etc), the second and the third are
table used for layout, but I'd made a difference between simple 2 to 3
columns table used for very simple layout and 5+ X 5+ cells table used
as a mosaic/tile framework to build complete new 2D rendering engine.
I think it's OK to allowed the simple layout kind, providing the
linearization is trivial.
> 4. TBD
> For tables of text and numbers, provide an alternative page which
> presents the table information in a linear fashion. [Interim]
> There are several ways to link to alternative pages which are described
> in more detail in Methods for linking to alternative pages. This has
> not been rated because we couldn't decide if this was required or
> recommended.
DD:: Recommended.
> Testing tips
>
> * To predict how one of today's screen readers might read your table,
> hold a piece of paper up to your monitor. As you slide the paper down
> the monitor, read the words above the line the paper creates as a
> sentence. Ask another person to listen as you read the page out loud
> without pausing for column gaps. Can he or she make sense out of what
> you have read?
DD:: Interim testing tips, it should say so.
> * Another method, to predict how a screen reader will interpret your
> page, is to save it as a text-only file then open it with a word
> processing program. This function is available in the "File" menu in
> most browsers.
DD:: The [New] testing tip should point to lynxit URL service.
> Links - Hypertext and Media-Independent Links
>
> 1. [Recommended]
> Create link phrases that make sense when read out of context (but
> they are not too verbose).
> A user should be able to select a link from a list of all of the links
> on a page without reading the context in which the link was used. For
> example, using "click here" as the text phrase for several links
> requires a user viewing the page with a screen reader to scout out each
> link to determine the context before selecting one. However, replacing
> "click here" with something more descriptive solves this problem. For
> example, "download this document in ASCII text," "view the full version
> in HTML," or "to view the text version, click here."
DD:: Required
> 3. Methods for linking to alternative pages:
> 1. Provide a visible link at the top of each page to allow a user to
> move back and forth between the graphic and alternative versions
> of the page.[Interim]
> 2. Provide the appropriate information in the header of the page so
> that the browser loads it automatically.[New]
> If the user has set their default media type to "speech" this will
> load the alternative page automatically:
> <HEAD><LINK title="Text-only version" rel="alternate"
> href="text_only.html" media="speech"></HEAD>
DD:: We should make it clear it's not an either/or solution.
I'm not sure about the media=speech part, I need to check (there's
also tty for instance).
> Frames - Multi-view presentation of documents
>
> 1. [Required]
> Provide a <NOFRAME> option for each <FRAMESET>.
> When using the <NOFRAME> option it is easiest to include all essential
> information on the bottom of the main frame.
>
> 2. [Recommended]
> Title each frame.[New]
> For example:
> <FRAMESET cols="10%,90%" title="Our library of electronic documents">
> <FRAME src="nav.html" title="Navigation bar">
> <FRAME src="doc.html" title="Documents">
> </FRAMESET>
DD:: Adding a title is Required, adding a longdesc is recommended.
> User-Input Forms
DD:: Should add a blurb at the beginning saying HTML4 has lots of new stuff
for FORM. (thanks to T.V)
> 8. [Recommended]
> Include a phone number, e-mail address, postal address or fax number
> for submitting information.
DD:: Interim.
> Tips and tricks to further enhance the usability of pages
DD:: I'm not sure a separate section is a good choice (rather than trying
to integrate its content in the main document)
> 1. If, after best efforts, any page is still not accessible, provide a
> link to an alternative page which is accessible, has equivalent
> information, and is maintained with the same frequency as the
> inaccessible page.
DD:: I think that should go right before the section on alternate text
linkage (use of LINK)
> 2. Use the "title" attribute on horizontal rules <hr title="new section">
>
> 3. Use the "title" attribute for acronyms and abbreviations
> <abbr>title="World wide web">WWW</abbr>
>
> 4. Use the "title" attribute for very short sounds <a href="mittens.wav"
> title="meow"></a>
DD:: Why here and not in as first class guidelines ? (maybe on title)
> 5. Avoid using ASCII art or replace it with an image and alternative text.
> Common typographic characters or constructions to be avoided are
> emoticons, arrows consisting of dashes and greater than signs -->,
> etc..
DD:: With image ?
> 6. Provide keyboard shortcuts for links.
> The "accesskey " attribute of <LABEL>, <A>, <CAPTION> and <LEGEND>
> allows an author to associate a keyboard shortcut with the phrase. For
> example, when associated with a link, it takes the user to the
> associated document. <A accesskey="C" href="doc.html">Press C to go to
> XYZ page</A>
DD:: with link ?
> 7. Front-load link phrases in lists.
DD:: ??
> Good Web Site Design Practices
>
> 1. Page layout is consistent but pages or areas do not look identical.
>
> 2. A clear, consistent navigation structure is used.
>
> 3. Navigation bars provide easy access to the navigation structure.
>
> 4. Instructions are provided to describe the general layout of the site,
> the access features used, and how to use them.
>
> 5. A site map is available.
>
> 6. Different types of searches are available for different skill levels
> and preferences.
>
> 7. Nothing within the site prevents keyboard operation.
>
> 8. Elements outside of the HTML 4.0 specification (such as <BLINK> and
> <MARQUEE>) are not used
DD:: Doesn't hurt repeating but that's not a "web site" practice
(i.e. something with a cross-page meaning)
> 10. Test the site with AT LEAST:
> o a text only browser (such as Lynx)
> o a self-voicing browser (such as PWWebspeak)
> o Multiple graphic browsers, with:
> + sounds and graphics loaded,
> + graphics not loaded,
> + sounds not loaded,
> + no mouse
DD:: I'd reorg as
- lynx (thru a lynxit service) [required]
- the others [recommended]
Received on Monday, 8 December 1997 12:46:13 UTC