Thursday, 4 February 1999 4:00 - 5:30 PM EST
There is a difference between decorative and critical ASCII art (as with other images). The focus should be on multi-line images rather than on emoticons (for example). For multi-line art, there are 3 possibilities:
for emoticons: use ABBR or SPAN with "title" (as per existing SPAN example, propose to include ABBR)
Action item for Ian to find out from UA what the status is of discussions concerning hiding d-links.
The group agreed that we ought to lean into the future on issues like d-link where an elegant solution has been devised but not widely supported. Therefore, we ought to highlight the use of "longdesc." Until "longdesc" is widely supported a proxy or some tool could convert "longdesc's" to d-links. Thus, Daniel will take the idea to the ER Working group. However, where information is critical for understanding TODAY, d-links are still a top priority (until a proxy and/or user agent supports longdesc).
Conclusion: we don't need to create a standardized way of marking up d-links. Instead we ought to focus on pushing someone to create a tool that will convert longdesc to d-link (for short-term and backwards compatibile solutions).
In the issues list, it is noted that there is concern that the techniques between OBJECT, IMG, and FRAME are not consistent and therefore might be confusing for authors. While confusing, the differences stem from OBJECT being designed to alleviate issues caused by the original design of IMG, APPLET, and the non-standard EMBED. Therefore, we ought to recommend that OBJECT be used as designed: textual content ought to always be used within the content of OBJECT (whether it be a short "alternative text-type" of phrase, or a long description) and that "title" ought to be used as a name, but not required.
We did not discuss this issue on the call yesterday because I felt that section A.2 of the Techniques Document has been rewritten to handle this issue. Do people agree or do we need more definition?
This issue was not discussed because the proposal to "Create and test new examples. If they work add to the techniques doc" has not yet been completed. Once completed we ought to discuss. Any volunteers?
We answered the following questions during the call:
Q1. The example places the "accesskey" attribute on the LABEL
element associated with the form control. Is it appropriate for the LABELs to
have "accesskeys" or should the controls have them?
A1. The HTML spec says that "accesskey" may appear on links, form
controls, and labels. Therefore, if the label and control are associated, it
shouldn't matter.
Q2. Does "accesskeys" introduce or create any usability issues?
For example, should this be a UA thing or should authors continue to create?
A2. As in other software, the author/authoring tool ought to create them, while
the UA handles displaying and using them.
Q3. What about pages that have too many elements to have unique accesskeys,
is this poor design? Should the form be broken up onto different pages?
A2. yes, this is bad design. Since accesskey uses unicode, there are 36,000
characters to use for accesskeys .
Q4. Are there implications on future versions of HTML?
A4. We did not come up with nor forsee any.
The following "rel" values on links have been proposed. We determined we did not need any of them per the reasoning that follows each proposal.
7.1. dlink Mark a link as an image descriptor (see also the "D-Link Reference for Browser Detection" discussion) - since we determined earlier in the call that we ought to focus on "longdesc" rather than d-link and that a tool could be created to convert a "longdesc" to a d-link, we don't see this as necessary.
7.2. navbar Mark a link as part of a navbar - due to agreement on how to handle groups of links in a later issue ("Grouping and bypassing links") it was determined that this rel value was not needed.
7.3. lintable Mark a link as part of a linearized table - once again, this is not needed because of other guidelines related to tables and tools that are in development that can navigate tables.
7.4. transcript Mark a link as a transcript of a audio file - this can be handled using OBJECT by either including the text of the trascript in the body of the element or linking to from within the body. Also, SMIL can handle. therefore it is not necessary.
7.5. Are there others we want to define? Although it is a neat idea, we could not think of any that we need to define at this time.
We determined that we do not need to include further instruction in designing color contrast since other places, particularly the Lighthouse do a fine job. Therefore, we already link to them and this is sufficient. Also, with the emphasis on style sheets and the ability of users to overwrite author settings, the emphasis on the accessibility of this issue diminishes.
We concluded that the best place for a "d-link" to appear on a frameset is within the content of NOFRAMES since the "longdesc" on FRAME was intended to describe the frames role in relation to the other frames. The NOFRAME description can act as an overview. Also, see the discussion on d-links. If "longdesc" is provided on frames, the proposed "d-link-to-longdesc" tool would take the longdescs from the frames and put them in the NOFRAMES.
This was not discussed on the call since it seems to me that the Proposal ("Send these suggestions to PF to investigate") is the answer.
Of the five proposals, a hybrid approach of a few of them is what the group on the call was happiest with. Therefore, we propose two strategies. The first should always happen, the second is supplemental.
11.1 Group related links (such as those in a navigation bar) using any appropriate element (P, FRAME, DIV, SPAN) and label the group with class="nav"
11.2 Use "tabindex=1" on a link that appears at the beginning of the "meat" of the content.
A further conclusion is that we do not want to recommend the MAP element as a way to group links since it is a non-standard use of the element.
We determined that there is at least one good use of frames that can not be accomplished using style sheet positioning: one frame is an index of documents, the other frame is where the content of selected documents appears. We agree there are problems with frames, but at this point they can't be ruled out entirely. However, we wish to discourage the use of frames in favor of style sheet positioning where applicable. This is similar to our position on tables - don't use them for layout, use positioning. Again, we wish to look to the future with our recommendations on this issue.