Hello,
The minutes from Thursday's meeting are fairly sparse compared to
previous minutes because we didn't need to spend much time on any one
issue. Here is our list of proposed resolutions to the first 12 issues
of the Techniques Document open issues list
[1]. If
further discussion is needed, please start a new thread with the
appropriate subject.
Participants:
Daniel Dardailler
Ian Jacobs
Jason White
Chuck Letourneau
Gregg Vanderheiden
Wendy Chisholm
1. ASCII art
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:
1. create a link to skip over (an example is included in the next
release of the techniques document as well as the modified checkpoint in
the guidelines document as discussed in a previous telecon).
2. use within the OBJECT element (as per existing example)
3. replace with image and alt-text
for emoticons: use ABBR or SPAN with "title" (as per existing
SPAN example, propose to include ABBR)
2. D-Link Reference for Browser Detection
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).
3. Long descriptions on OBJECT without "longdesc"
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.
4. Definitions for alt, title, and longdesc
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?
5. Using NOFRAMES in a BODY element
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?
6. "accesskey" example
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 <grin>.
Q4. Are there implications on future versions of HTML?
A4. We did not come up with nor forsee any.
7. Definition of "rel" values on links
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.
8. Color design guidelines and examples
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.
9. "d-link" with frames
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.
10. Recommendations for future versions of HTML
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.
11. Grouping and bypassing links
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.
12. CSS2 vs. frames
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.
Thoughts on any or all of these!?! Please, start separate threads for
each issue.
We will be having calls the next two weeks (see the home page or
Gregg's earlier message for details).
If no further discussion occurs on any item, I will consider it closed
and modify the open issues list and Guidelines/Techniques documents
accordingly.
--wendy
[1] the Techniques Document open issues list -
http://www.w3.org/WAI/GL/wai-gl-tech-issues.html