Current: Section 1 Recommendation 1: Use style sheets to position text and objects, etc...
Discussion:
Comment 1: 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.
Comment 2: Changed from required to recommended
Comment 3: my original comment was just to take out the table line in this section, not to change the whole Style section rating. But we discussed that a little on the list and my last batch of comments didn't ask for any change. So we can keep it (the table line) in the Style REQUIRED set as far as I'm concerned, as long as we change the TABLE section itself (which you are doing).
Comment 4: keep it required as long as say more about tables later.
Action: Item is Required. Added note about support of positioning in current browsers.
References:
Current: Section 2 recommendation 5: Provide descriptive titles for all images used as links.
Discussion:
Comment 1: Upgrade from [RECOMMENDED] to [REQUIRED].
Comment 2: As long as alt-text is provided for these images, users will be able to use these images as links. Descriptive titles will increase the usability. Therefore this would appear to be a [RECOMMENDED] item.
Comment 3: REQUIRED in this context re-enforces the idea that IMG in A with no desc are twice as bad as simple IMG with no desc. If we get this message out somewhere else, that's OK with me. We also need to have the discussion on usage of ALT/TITLE/etc before closing on this one.
Action: No action taken at this time.
References:
Current: Section 8 Recommendation 1: Create link phrases that make sense when read out of context.
Discussion:
Comment 1: Change this item from Recommended to Required Even though this is something the browser could have a say about, and help with, I think we should make it a required as it is really a very important navigability issue
Comment 2: Should this be required? Does it prevent the use of the page or only make it harder. Also, it is not always possible to create link phrases that make sense when read out of context is it?
Comment 3: Doesn't meet the definition of required. We would need to change the definition to include things that are helpful. That would weaken the required label but allow us to put more stuff in it. We may not have a justification for using the work required though if we did. Your thoughts? [Editors 02 Feb 1998]
Action: No action taken at this time.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0032.html
Current: Section 5 Recommendations 1,2,3. HTML structural elements are only used to convey meaning, not presentation. HTML presentational elements are only used to convey presentation, not meaning. Headings are nested properly and are not used for layout.
Discussion:
Comment 1: Change all 3 From Recommended to Required, they need to be at the same level as using SS at the beginning.
Comment 2: If SS are moved from required to recommended, does this comment still apply?
Comment 3: If these are not followed will the page be inaccessible or just less usable? I guess in some instances, not following this will make the page inaccessible (or at least very difficult to access). I could agree with moving this up, do others agree?
Comment 4: Shouldn't item two say "HTML presentational elements are only used to convey presentation, not structure." since most all presentation contains some type of meaning?
Comment 5: SS stays REQUIRED. See comments on issue 1 (style sheets).
Action: Moved from recommended to required. Item two also edited to say structure.
References:
Current: Section 5 Recommendation 4: Avoid blinking or scrolling text.
Discussion: Make this one required.
Action: Changed to required.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1997OctDec/0025.html
Current: Section 6 Recommendation 1. List structure and list items are correctly encoded.
Discussion: From Recommended to Required - same thing as above.
Action: Changed to required.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0032.html
Discussion:
Comment 1: In the Applet section, I think there is too much Required. Given that Java Accessibility is going to be a reality, we should force people to transcribe their applet in some other formats.
Comment 2: Java Accessibilty is not now a reality and it is not clear when it will be (or how successful or how universal the accessibility will be)
Comment 3: Not all browsers support Java
Action: No action taken.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0032.html
Current: Avoid using tables to arrange text documents in columns or otherwise layout a page. [New] Authors should use style sheets to position graphics and text.
Discussion: 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.
Action: Broke this up into two guidelines.
1. [Required] Avoid using tables to arrange text documents in columns.
2. [Recommended] Avoid using tables to layout a page. [New] Authors should use style sheets to position text and graphics.
Also note that further down in the list is: [Recommended] For tables of text and numbers, provide an alternative page that presents the table information in a linear fashion. These have all be grouped together.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1997OctDec/0025.html
Current: 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.
Title each frame.[New]
Discussion: Adding a title is Required, adding a longdesc is recommended.
Action: Made "title" required, "longdesc" was already recommended.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1997OctDec/0025.html
Current: Section 9 Recommendation 1: Ensure that your pages are readable and usable without frames.
Discussion:
Comment 1: From Required to Recommended, or an Interim. A browser issue really.
Comment 2: <NOFRAME> does not seem to be an interim solution. Currently, if NOFRAME is not provided, the page is inaccessible (thus required).
Comment 3: HTML4 specs: "In addition, the FRAMESET section can contain a NOFRAMES element to provide alternate content for user agents that do not support frames or are configured not to display frames." So this is an interim thing. You said it yourself: "Currently...."
Comment 4: 9.1 Frames and NOFRAME I still think strongly that we got this one backward: it's not a [New], it's an interim (even though FRAMESET are new in HTML4, they've been around for a long while in products, and lynx already handles them). [Daniel Dardailler 30 Jan 1998]
Comment 5: How will browsers render a "noframes" version without <noframes>? Even if browsers are able to effectively navigate between frames, it seems there will be instances where people would prefer a "noframes" version. For example, users of small displays. [Editors 02 Feb 1998]
Action: No action taken pending more discussion.
References:
Current: 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?
Discussion:
Comment 1: Interim testing tips, it should say so.
Comment 2: It says, "To predict how one of *today's* screen readers..." therefore would seem to already imply interim. (also testing tips are not otherwise labeled).
Comment 3: I guess my point is that the tips should be rated as well wrt timing. [Daniel Dardailler 29 Jan 1998]
Comment 4: Most all of the tips are not new or interim so they would have no label on them (like the strategies don't). I think there is only one that is interim and it says that it is just for today's browsers. Do you see other tips that need to be labeled? [Editors 02 Feb 1998]
Action: No action taken.
References:
Current: Include a phone number, e-mail address, postal address or fax number for submitting information.
Discussion:
Comment 1: (Daniel Dardailler) Interim.
Comment 2: (Editors) Isn't it always a good idea to include this information if someone is having problems accessing the information?
Comment 3: (Daniel Dardailler) But isn't it the case that people are having problem in the interim only ? because their tools are not good enough to use the form as is.
To me, this is about changing the content of the information, which is something I'm opposed to: the source should be the same for everybody, it just needs to be accessible to all media.
Action: Made it interim, as well as, "Include default, place-holding characters in edit boxes and text areas."
References:
Discussion: regarding the discussion on ratings and how many classifications: i think you can get by with two classifications as long as the "required" rating has stronger language. right now it says "Required for some groups of users to access the information on a page." this doesn't sound vital enough to me. how about something like, "Required, otherwise pages will be impossible to read for some groups of people." this being the case, there should be a definition of these groups of people (blind, VI, deaf, HOH, etc.).
Action: Made language stronger.
Discussion:
Comment 1: 8.2 (links in a horizontal list): this should be upgraded to "required". placing a printable character (like a vertical bar) between links makes it easier for everyone to scan the list. [Geoff Freed 29 Jan 1998]
Comment 2: doesn't meet the definition of required (see Issue 3). [Editors 02 Feb1998]
Action: No action taken at this time.
Discussion: The guidelines provide an example of an image map in which the coordinates of the active regions are given in anchor elements, as permitted by HTML 4.0. This version of HTML also allows block-level content to be included in MAP. The example could be enriched by providing a more detailed description of the library within the MAP element, such as would appear from the image map (for example, a brief synopsis of the layout of certain facilities). [Jason White, 19980124]
Action: No action taken at this time. This is an excellent suggestion for the next version. We would appreciate a draft.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0030.html
Discussion: The guidelines suggest taking advantage of the media attribute of the LINK element to facilitate automatic retrieval of "text only" alternative documents, where these are deemed necessary. While I would not disapprove of this approach, I would emphasise that alternative pages should be avoided wherever possible. As Daniel has correctly stated on more than one occasion, the goal of the WAI is for there to be a single document which can be rendered in different media with equal success. In relation to the technical side of this proposal, the HTML 4.0 specification (at 6.13) defines a media type of "aural" for speech synthesizers, rather than "speech" as is incorrectly claimed in the guidelines. Also, to encompass all types of non-graphical devices, the MEDIA value should read: media="aural, braille, tty".
Action: Moved the alternative page stuff to a section called "If all else fails..." All references to "speech" were replaced with "aural." The cited example was changed to include braille and tty. The reference to the full list of media types was updated to include tv and handheld.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0030.html
Discussion: "Comments" section. I don't like the sentence that says: "We cannot guarantee a personal response but we will try when it is appropriate." Basically, this means: we can ignore your comment/request if we want, and that's not acceptable. We need to point people to an up-to-date "issue list" document where *all* the issues raised are stored together with their status (need more discussion, ok to be incorporated, no for this and this reason, etc) and their origination (author, date, pointer to message/thread).
Action: The sentence was deleted. A document has been created in response to your request, from which this is excerpted.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0032.html
Discussion:
Comment1: Section 2 Recommendation 5. We should also add "descriptive link title", or "description anchor title" to disambiguate with the IMG title.(the example is clear, but it's dropped from the checklist for instance)
Comment2: this might make the guideline confusing. The checklist is to remind them. The guidelines includes the example if there is confusion. Do you see it as a big problem?
Comment 3: Why would this make the guideline or checklist confusing since it adds more context ? I think there is a real risk of misunderstanding and using the IMG title.
Action: changed to: All images used as links have descriptive link titles.
References:
Discussion: Section 12 Recommendation 12. Test the site with at least: a text only browser (such as Lynx) a self-voicing browser (such as PWWebspeak) I think requiring lynx is OK (given web ready lynx-it service) but self voicing is unrealistic.
Action: Created a new bullet that says, "It may also be helpful to test your site with a self-voicing browser (such as PWWebspeak)."
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0032.html
Discussion: We should probably advise people to use the OBJECT element and not APPLET.
Action: Note added to recommendation concerning APPLET element that says it has been deprecated.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1997OctDec/0025.html
Discussion: "Good Web Site Design Practices" is very close to the name of an existing document, "Good Site Design Practices," by Tobias C. Brown et al, started in November, 1997, and posted regularly to comp.infosystems.www.authoring.site-design. The two documents seem to compliment each other. Maybe you would be interested in adding authoring tips to spell check, copyright, and promote a site correctly. You can find the history of this document at Deja News, on Usenet now in the aforementioned group.
Action: Yes, a great document. The suggestion and a few of the links relating to validation and lynx type services were incorporated. Have included this in the reference section of the central document.
References:
Discussion: "Status of this document" section. unfinished sentence: The goal of the WAI-GL group is to ... I think it should point to the charter.
Action: The sentence now reads, "The goal of the WAI-GL group is discussed in our charter." with "charter" acting as a link to the charter.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0032.html
Discussion: Section 3. Applets and Scripts Say upfront that APPLET is deprecated.
Action: Added a note.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0032.html
Discussion:
Comment 1: Need more examples for AUDIO/VIDEO. I understand this could go in the Central Reference but as is, it is inconsistent with other section, such as image, form, which are full of example. Either they all get examples, or none of them do. I'm for putting at least a short example in all sections (It's nice that they are all marked with a class=example, and <CODE>)
Comment 2: Do you want examples of transcripts or how to link to the transcripts? Most of these guidelines discuss creating separate documents and would be hard to create HTML specific examples for.
Comment 3: DD:: Yes, I would like to see example of how to link to transcripts.
Comment 4: good idea, ran out of time for this draft. in process. please send examples if you have them. [Editors 02 Feb 1998]
Action: No action taken at this time.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0032.html
Discussion:
Comment 1: For the TABLE example appendix, I'd move it to the Central Ref and keep a shorter version inline (no appendix here in other words, besides the checklist)
Comment 2: I think the examples are very important to keep within the guidelines. Particularly those that show the new HTML elements.
Action: No action taken at this time pending futher discussion.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0032.html
Discussion:
Comment 1: Section 12 Recommendation 3. Offer navigation bars for easy access to the navigation structure. Apparently, pages that starts with a navbar are bad for sequential reading (speech in particular) as they force the listener to listen to the same navbar over and over again. I think we need to be a little more specific and I suggest we propose a authoring guidelines to "classify" navbar, using the HTML class attribute applied to the element used (frame, image map) or a DIV if there is no navbar element per se:
<div class=navbar>
<A HREF=foo>Search</A> | <A HREF=bar> Home </A>
</div>
This way a browser can move it down the page or offer it as an option on demand.
Comment 2: Should we wait to recommend this until the UI group has created a guideline for the browser side of things?
Comment 3: yeah, you're probably right, we need to wait for the UI group to tell us what they need in terms of Markup to achieve a good UI. 19980130
Comment 4: What I might like to see here is a some sort of a caution, with a hyperlink to wherever the "too many introductory links" problem is discussed. This is an area where the technology doesn't yet offer a universal solution, so an unqualified "Do this:" is misleading. 19980130
Comment 5: In the discussion of navigation bars on this list, it has been noted, correctly, that further work is needed in this area, both in the PF group and in respect of the interfaces provided by HTML user agents. It would however seem clear that some means of isolating the HTML block comprising the navigation bar is needed, such as the use of the DIV element with CLASS="navbar". Perhaps this could be introduced into the guidelines as a "new" and "recommended" item. Also, it may be preferable for authors to use the LINK element within the head section of the document, together with the link types listed in section 6.12 of the HTML specification, whenever practical, as a substitute for a navigation bar in the body of the document. The rendering of the LINK element is left entirely to the user agent, and this maximises the availability of presentation (braille or speech-based software could provide a user interface option that offers access to the list of links in the head of the document, rather than presenting them at the start of the document itself). This strategy would of course require complementary work within the UI group to ensure that visual user agents provide a common and acceptable rendering of LINK elements. [Al Gilman 19980201]
Comment 6: Guidelines should say something about making use of the "div" element for navbars. Or use the LINK element in head as a substitute for a navigation bar in the body of the document (which would required some discussion with the UI group on how and when this gets rendered). [Jason White 19980201]
Comment 7: great ideas. we ran out of time on this release, i.e. there is no cautionary note to link to at this time - that we're aware of - and we need to discuss other possibilities further. Do you have suggested wording? [Editors 19980202]
Action: No action at this time pending further discussion and development.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0032.html
Discussion:
Comment 1: The theme of his message is that as well as the guidelines saying 'what' needs doing, it would be helpful if advice were given on 'how' an accessible site can be developed (or an inaccessible site updated to improve accessibility).
Comment 2: Great suggestion. The case studies that we intend to create for problem issues would satisfy this request. However, a test page that uses all of the guidelines would be an interesting thing to attach to the guidelines. (I hope it is possible (smile))
Action: No action taken at this time pending further discussion and work.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0037.html
Discussion: Sections 5 and 7 testing tips: 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.
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.
The [New] testing tip should point to lynxit URL service. Provide a link to a lynx-it kind of page.
Action: Links to these types of services were added.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1997OctDec/0025.html
Discussion: Should add a blurb at the beginning saying HTML4 has lots of new stuff for FORM. (thanks to T.V).
Action: Added several new recommendations in the forms section. Still need a blurb?
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1997OctDec/0025.html
Discussion:
Comment 1: In a message just sent to the WAI interest group, I remarked that the page author guidelines were intended for several distinct audiences: (1) individuals who are creating web content; (2) software developers whose applications, whether they be authoring tools, file conversion packages or other products, generate documents in formats such as HTML which are intended for delivery via the Web. A brief note drawing attention to the intended audience could be added to the introductory paragraphs of the document, thus drawing it to the attention of the groups for whom it was written. http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0071.html Jason White
Action: see new section at the beginning "Abstract." 19980130
Discussion: section 4 (audio and video): captions are familiar by now to many people, but not all. even fewer people are familiar with audio descriptions. i think section 4 would benefit from one-sentence definitions of both captions and descriptions and, while you're at it, transcript. as i mention below, i don't think transcript and captions should be used interchangably.
Action: added definitions and reworded. 19980130
Discussion: section 4.2 requires that descriptions be provided; i think a link to an example would be very helpful. at the risk of tooting ncam's horn, you could link to one of our movies (for examples of both captions and descriptions). when sami and smil have reached the stage where examples are available, you could link there in future versions of the guidelines.
section 4.4 alludes to using captions with video but refers to them as a transcript. i think you should draw a distinction between a *transcript* as a non-synchronized representation of the program audio-- that is, a simple page showing nothing but text-- and *captions*, which actually are synchronized to, and are displayed alongside, the video. section 4.1 could define "transcript", and section 4.4 could define "captions." while we're defining things, section 4.2 could provide a definition of audio descriptions.
Action: Added a link to the NCAM site. 19980130
Discussion:
Comment 1: If the PRE element contains computer programme code rather than text in a natural language, this fact should also be marked for the benefit of braille and speech output software, perhaps as class="code". Standardised class values are an important component of accessible HTML document construction, since they will also enable the reading order of the document to be modified by the HTML user agent. This topic will presumably be discussed within the Protocols and Formats group [Jason White 28 Jan 1998 http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0039.html ].
Comment 2: I think using HTML's CODE element inside the PRE element would be better than reliance on classes in this case since CODE gives the structural information to all early browsers. Authors could use the CLASS attribute on CODE to indicate the kind of code, e.g., class="HTML" or class="Java". Speech browsers could then process common kinds of code more appropriately. [Liam Quinn 28 Jan 1998 http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0041.html ]
Comment 3: Without re-reading the HTML specification on this point, I am under the impression that any markup inside the PRE element (prior to the end tag of PRE itself) is treated as part of the preformatted text rather than as markup. My memory may be wrong here, however. If I am right, then using the CLASS attribute of the PRE element to distinguish code from text in a natural language would appear to be the only feasible option. [Jason White 30 Jan 1998 http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0074.html ]
Comment 4: No it's OK, you can have CODE in PRE: [Daniel Dardailler 30 Jan 1998 http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0075.html ]
Comment 5: A better solution would be to separate the semantics from the presentation by using the "white-space" property [Example deleted]. However, this would only work for CSS-enabled browsers. [Ian Jacobs 30 Jan 1998 http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0079.html ]
Comment 6: I guess this means not acceptable, since this would break guideline 1.1... [Daniel Dardailler 30 Jan 1998 http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0081.html ]
Comment 7: Interesting possibilities that need to be discussed further. [Editors 02 Feb 1998]
Action: No action taken at this time pending futher discussion and work.
Discussion:
Comment 1: "8pt" used in the style sheet for [Recommended] and [Required] is almost illegible on a Macintosh. The CSS specification says, "Absolute length units are only useful when the physical properties of the output medium are known." [1] Please use a relative size like 'small', and read the conclusions in my short paper on font-size in CSS (they will tell you x-small and xx-small are unusable as are sizes under 82-75%). [2] Incidentally, at small sizes, Helvetica is one of the least readable fonts on a Macintosh. Maybe not specifying font-family would help, too.
snippet in question
-------------------
span.rec {
font-family : Helvetica;
font-size : 8pt;
^^^
Efforts to improve accessibility might include efforts to improve readability for sighted Web users as well [3]. I have no formal qualifications beyond a degree in Studio Art, but if I can be of assistance, please let me know.
Comment 2: Excellent comments. Changed to 9pt default font. More when we test to see which approach will work best. Also, use of style sheets will be remedied next version of the guidelines.
Comment 3: Font sizes specified in points should be avoided. If a poor-sighted user views the page with his 24pt default font, the 9pt font will be unreadable to him. When I view the page with my 14pt default font, the 9pt font looks out of place. We should specify the font size in percentages if at all. This may be worth mentioning in the guidelines.
Another problem for sighted users is the use of things like <BODY BGCOLOR="#FFFFFF">. While this is common on the Web, I think it represents an accessibility problem. If the user's text and link colours are too different from typical browser defaults, the page may be unreadable. As an example, consider a user who has configured her browser to use white text on a black background; this user will see white on white unless she overrides all author colours, which shouldn't be necessary (but is on today's Web). Recommendation: If one of the BGCOLOR, TEXT, LINK, VLINK, or ALINK attributes is given, then all should be specified. The BACKGROUND attribute should also be accompanied by the other BODY colour attributes.
Comment 4: Liam wrote: > Font sizes specified in points should be avoided. DD:: Agreed.
Comment 5: (in re: background color from Comment 3) Yes, this is a rule we have applied with a script to the whole W3C site a while ago. But I'm not sure it's worth mentioning in the document as this is easily overruled by use of CSS "body: { color : white }" clause.
Action: Excellent comments. Changed to 70%. More when we test to see which approach will work best. Also, use of style sheets will be remedied next version of the guidelines.
References:
Discussion: Tips and tricks Section. I'm not sure a separate section is a good choice (rather than trying to integrate its content in the main document)
Action: Content has been integrated back with other sections, except for the alternative page recommendation. This stands alone in the newly titled section, "If all else fails..."
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1997OctDec/0025.html
Discussion:
Comment 1: "If all else fails" section. I think the recommendation for an alternative page should go right before the section on alternate text linkage (use of LINK)
Comment 2: At the meeting in Austin we discussed what to do with this recommendation. Many felt that it should be at the end of the page so that people wouldn't fall back on it before reading the rest of the document.
Action: Item left at end per Austin discussion.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1997OctDec/0025.html
Discussion:
Comment 1: Use style sheets to get rid of the brackets around "Required" and "Recommended" (when style sheets loaded, visible when not). Also use SS to put border around "new" and "interim" [Daniel Dardailler 30 Jan 1998 http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0077.html ]
Comment 2: borders do not seem to be supported for MSIE 4.0. The loss of the brackets around "required" and "recommended" makes the characters difficult to read (the white characters bleed into the white background). We are continuing to look at ways to do this better that work on the different browsers (both for viewing and for printing). It is not easy to find things that work. Suggestions always welcome. [Editors 02 Feb 1998]
Action: No action taken at this time.
Discussion: Comment 1: 2.1 Image ALT I think 2.1.4 that would say something like : for decoration image, uses ALT="", even if we don't all agree, is better than saying nothing on the topic in the first public draft. [Daniel Dardailler 30 Jan 1998 http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0076.html ]
Action: No action taken at this time pending further discussion.
There have been several comments on providing more specific guidelines about the use of alt-text. We have deferred action on these suggestions until consensus is reached on these issues. A discussion thread will be posted in the near future to begin this process. This discussion will include the title element on anchors (for images used as links). [Editors 02 Feb 1998]
Discussion:
Comment 1: We need to talk about list that use image as bullet here, as it is one of the most recurrent abuse of HTML structuring. I'm reposting my 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 so that you don't get double bullet)
UL { list-style: none }
<UL>
<LI> <IMG SRC=browneye.png ALT="bullet. brown eye drawing"> Audrey
<LI> <IMG SRC=greeneye.png ALT="bullet. green eye drawing">Laurie
<LI> <IMG SRC=blueeye.png ALT="bullet. blue eye drawing">Alice
</UL>
Comment 2: It is hard to include this in the recommendations without consensus on what the alt-text of bullet items should be. We are at the tail-end of the process of gathering all of the discussion points associated with alt-text. A whole section is devoted to this topic. We agree something needs to be said, but resolution and consensus should be reached first.
Comment 3: DD:: Regarding Issue 7 "list that use image as bullet here" OK we need to discuss more the case, but I think the part that explain how to deal with purely decorative bullet is a no brainer UL { list-style: url(button.png) } There is no opportunity to put any ALT in here anyway.
Action: No action taken at this time pending futher discussion.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0032.html
Discussion: A "tips and tricks" note could be added to the discussion of ALT text to assist authors in deciding what to write as a label or description of the image. Perhaps a good test would be as follows: if you were reading the document aloud over the telephone, what would you say upon encountering this image to make the page comprehensible to the listener? Aim for a functional and contextualized label or description rather than a visual description. This suggestion is based on a comment made by Al Gilman a number of months ago.
Action: No action taken at this time pending further discussion on alt-text.
References: http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0030.html