EOWG Meeting, July 16, 1999, Minutes

EOWG Meeting, July 16, 1999, Minutes.

NOTE #1: EOWG members present at July 16th meeting should check the minutes
regarding "Quick Tip" discussion in detail by 2:00 p.m. US EDT, July 16. --
Thank you.

NOTE #2: From the "Quick Tips" discussion below, items #8, #10, and #11 are
unresolved and must be resolved by 2:00 p.m. US EDT.

NOTE #3: Because we didn't get to the WAI home page re-org, please comment
on line. Also be on the lookout for SMIL access features note.

Present:
WL William Loughborough
HB Harvey Bingham
GF Geoff Freed (at the beginning only?)
HBj Helle Bjarnø
AC Alan Cantor
CMN Charles McCathieNevile
MRK Marja-Riitta Koivunen
JT Jeffrey Turner
KH Karl Hebenstreiht
JA Jim Allan
JB Judy Brewer

1. Outreach updates
WL We got a mention in Ragged Edge.
WL, HB (US) FCC announced Rule on Section 255 of Telecommunications Act;
it's getting some publicity for technology access.
HB Presenting next Tuesday at DAISY Consortium and (US) National Library
Services.

2. Action Items review
Events Page 
- JB will follow up with Jim Allan on web site access and to add a last
updated site. (CMN will be a back up to get information onto the site). DONE.
- JB to send a message to the interest group reminding people to list new
events. NOT DONE.
- JB will add mention of this right on the WAI home page. DONE.
- JB will rename current "event" heading to "history" and include curric.
DONE ON NEW DRAFT SITE.

WCAG Curriculum.
- CL: to ping Phil Jenkins on his promised comments from IBM. DON'T KNOW IF
DONE.
- SS & MRK: to review and send comments today if possible. MARJA DONE.
- CL: to send Judy a message when the final compile and update is ready so
she can make some release noises. CL DONE, JB NOT DONE.

Outreach updates 
- CMN: will take notes on this and post to Event's list. DONE.
- JB: will owe us an explanation on EITAAC. NOT DONE.

Quicktips Card changes 
- JB: will roll together list of proposed changes and drop the second half
and put an "and" between the first two clauses. DONE. ALSO DID A SUMMARY.
- DD (CMN) to review the quicktips to see if they are in line with the
priorities of the WCAG. NOT DONE, BUT OTHERS DID.

WAI Page update 
- JB: to put a note to the list asking for discussion of and nomination of
categories for the WAI page site redesign. SENT OUT A RE-DRAFT INSTEAD.

3. Agenda review. 
JB Priority is to finish Quick Tips card today, and comment on home page
re-org. May have SMIL access features draft later today for review. WAI
Overview curriculum not revised yet.
WL What's that?
JB the on-line presentation I did in April of an overview of WAI; not
updated for discussion yet.
Purpose of discussion: consider edits needed to correct or clarify existing
text, before reprinting large quantity.
Constraints: 
- very very small space; 
- agree on text by Friday about 3:00 p.m. US EDT.; 
- text cannot differ from messages or priorities of WCAG 1.0.

The following section summarizes all comments received by Friday morning,
and proposes a resolution for each item. Comments are (roughly) attributed
to individuals and you can look for their rationales in the EOWG mailing
list archive at
<http://lists.w3.org/Archives/Public/w3c-wai-eo/1999JulSep/>. I've added a
few additional replies into the summary, then made a "PROPOSAL." Then at
the EOWG meeting today we discussed these, hence, "DISCUSSION." In all but
two cases we agreed on something, which is marked "CONSENSUS." Finally,
decision on items #8 and #10 were deferred to the mailing list for
resolution over the next four hours by EOWG members.

I numbered the tips here for easier reference, although they are not
numbered on the card, and will not be.

Comments & proposal on card:

Quick tips to make accessible Web sites 
JB leave as is.
NO DISCUSSION. Will remain.

FOR COMPLETE GUIDELINES & CHECKLIST: WWW.W3.ORG/WAI 
JB leave as is.
NO DISCUSSION. Will remain.

1. Images & animations. Use the alt attribute to describe the function of
all visuals. 
HB change "all visuals" to "each visual".
DD make "alt" boldface.
RN "alt" should be in caps
JB other attributes aren't.
MM replace "the function" with "both content and function"
HB "function or content" but not both.
JB as I recall, the Guidelines WG gave us a mandate to use "function" here,
e.g., the purpose that the visual serves on a Web page; in some cases it's
the same as the content. I looked at the discussion of text equivalents in
guideline one of WCAG, it says "The equivalent information must serve the
same purpose as the visual or auditory content." so I think "function" wins.
PROPOSAL: "Images & animations. Use the _alt_ attribute to describe the
function of each visual."
DISCUSSION: 
YES: CMN, HB, HBj, AC 
WL: Can live w/.
WL: drop function entirely: "Use the _alt_ attribute to describe each visual."
CMN, MRK: it's important
CONSENSUS: "Images & animations. Use the _alt_ attribute to describe the
function of each visual."

2. Image maps. Use client-side MAP and text for hotspots. 
JB Make "MAP" lowercase but keep bold.
RN Require redundant text links. add "and alternate text links"
JT: Alt text for client side maps (areas) is priority 1. Alternative text
links
is priority 3 because those areas are generally accessible today. Look at
www.ibm.com/sns which has a map across the top. All alt text is displayed
in IE
with images off, and spoken with screen readers and text browsers. Even
without
alt text, Lynx, HPR, and others will at least expose the URL's.  Your comment
seems to be talking about server-side maps - where you would get one alt text.
Not using these or providing alterntive text links is priority 1.
AG "Use client-side _map_ with text for hotspots." to clarify that the text
is in the map.
JB originally we put "and" here so it could be interpreted either way (in
the map, or as redundant text links). Crude, but that's what I recall as
the outcome of an excruciatingly long thread. Looking at the text of 1.5,
"Until user agents render text equivalents for client-side image map links,
provide redundant text links for each active region of a client-side image
map," keeping "and" actually looks truer to the intent.
RN Add "links" as follows: "and text links for hotspots."
AG Since redundancy is required for the interim, "Use a client-side
<em>map</em>, and text links as well as image hotspots."
JB Seems that adding "links" would clarify things. Unfortunately it also
blows the line-length, wrapping onto the next line, and thereby displacing
something else from the card. Is the additional clarity on this sufficient
to justify removing something else? If so, what should go...?
IJ In all the specs I've worked on, we've adoped the convention that
element names are in caps and attributes in small letters (and quoted). 
JB MAP was looking lonely as the only capitalized element or attribute on
the front; but you're right. However, if that means we've got to put little
quote marks around all the attributes, hmmm...?
AG doesn't have to be true to specification conventions, just needs to be
set off.
PROPOSAL: "Image maps. Use client-side _map_ and text for hotspots."
DISCUSSION:
AC Possible to "Use client-side _map_ and text links hotspots."
CMN Yes.
HBj Difficult to understand AC's proposal.
AC Can live with, WL, HB, HBj, JA, MRK
HBj What about "map" 
HB Use small caps MAP.
CONSENSUS: "Image maps. Use client-side _MAP_ and text for hotspots." (NB:
_MAP_ is in small caps.)

3. Multimedia. Provide captioning and transcripts of audio, descriptions of
video, and accessible versions in case inaccessible formats are used. 
JB drop "accessible versions in case inaccessible formats are used", add
"and" before "descriptions, drop that comma, shift the period.
GV concern about dropping that phrase.
RN "Multimedia. Provide captioning or text transcripts of audio.
Descriptions of video may be provided."
JB can't change priority of WCAG.
AG  "Provide captions and transcripts, and descriptions of video."
JB I think it's important to emphasize audio-- many people don't think in
terms of deaf access.
PROPOSAL: "Multimedia. Provide captioning and transcripts of audio, and
descriptions of video."
WL yes
JA yes
HB yes
HBj yes
AC Yes, KH, MRK, CMN
CONSENSUS: "Multimedia. Provide captioning and transcripts of audio, and
descriptions of video."

4. Hypertext links. Use text that makes sense when read out of context. For
instance, do not use "click here." 
WL Remove "For instance, do not use "click here."
HBj Yes on remove, but "include non-link printable characters between
adjacent links"
JB 
AG "Use text that makes sense when read out of context, not 'click here.'"
PROPOSAL: "Hypertext links. Use text that makes sense when read out of
context, not 'click here.'"
DISCUSSION:
CMN: replace 4 (don't use 'click here') with
Write clearly, use images and navigation consistently.
PROPOSAL: "Clarity. Write clearly, use images and navigation consistently."
Note: There is a deliberate ambiguity in "consistently", between doing it in a
manner which is recognisable across the site (very important) and a possible
alternative interpretation of doing it throughout a site (which is also
important, particularly for the cognitivve disability case.)
WL: Clarity is not clear, and the tip isn't concrete.
JB Interesting, high-level concept to miss out on.
AC Navigation, enticing...
WL change "hypertext links" to "navigation".
JB Navigation. Use sensible text links, and 
PROPOSAL: "Hypertext links. Use text that makes sense when read out of
context, not 'click here.'"
AC likes
CMN like sensible
JA understandable
JT Navigation?
MRK, AC, CMN. No. 
JT e.g, "e.g. 
CMN "not just click here"
WL Links.
JB ; for instance, avoid "click here."
AC . Avoid "click here."
HBj likes for instance.
JB me too.
HB use terse text
ALL hmmmm...
AC, HBj, HB prefer for example
OPTIONS:
1. Avoid "click here."
2. For example, avoid "click here."
HB 2
HBj 2
JA 2
CMN 2
2 wins... consensus
front is hypertext links still
CONSENSUS: "Hypertext links. Use text that makes sense when read out of
context. For example, avoid "click here."
     
5. Page organization. Use headings, lists, and consistent structure. Use
CSS for layout and style where possible. 
DD Make CSS bold.
PROPOSAL: "Page organization. Use headings, lists, and consistent
structure. Use _CSS_ for layout and style where possible."
DISCUSSION:
JA "Page organization. Write clearly, use headings, lists, and consistent
structure. Use _CSS_ for layout and style where possible."
JB line length problem.
HBj write clearly is not page organization.
PROPOSAL: "Page organization. Use headings, lists, and consistent
structure. Use _CSS_ for layout and style where possible."
supporting: CMN, HBj, AC, JA, KH, MRK, 
WL reluctant, wants to drop "where possible"
HB reluctant, wants to drop "CSS"
JB you cancel each other out
WL, HB: OK
CONSENSUS: "Page organization. Use headings, lists, and consistent
structure. Use _CSS_ for layout and style where possible."

6. Graphs & charts. Summarize or use the longdesc attribute. 
HBj Why is "longdesc" in bold?  All attribute names should be the same. See
also "title"  and "name" under Frames.
JB ?they are the same; they're all in bold, no?
PROPOSAL: "Graphs & charts. Summarize or use the _longdesc_ attribute."
DISCUSSION:
CONSENSUS: "Graphs & charts. Summarize or use the _longdesc_ attribute."

7. Scripts, applets, & plug-ins. Provide alternative content in case active
features are inaccessible or unsupported. 
PROPOSAL: "Scripts, applets, & plug-ins. Provide alternative content in
case active features are inaccessible or unsupported."
DISCUSSION:
HB applets inappropriate term
JB best comprimise from previous discussion
CONSENSUS: "Scripts, applets, & plug-ins. Provide alternative content in
case active features are inaccessible or unsupported."

8. Frames. Label with the title or name attribute. 
PROPOSAL: "Frames. Label with the _title_ or _name_ attribute."
PROPOSAL: "Frames. Use _title_ or _name_ attribute, and _noframe_.
DISCUSSION
CMN Use _noframes_
PROPOSAL: "Frames. Use _noframe_, and _title_ or _name_ attribute.
HB Use small caps for NOFRAME.
JB Noframe not priority one.
?? Not even a checkpoint; a technique
AC How'd it fall out of the guidelines
JB We can't use the card to disagree with the guidelines.
PROPOSAL: Leave as is.
NOT IN CONSENSUS: WL, AC, CMN, HB, KH, 
JB Discussion will continue over next four hours on EOWG mailing list. The
dissenters should propose a resolution that can will the support of other
active EOWG members and to which at least the editors of WCAG can agree.
Can also involve the Guidelines WG on this item if needed. 
ALL Agreed.

9. Tables. Make line by line reading sensible. Summarize. Avoid using
tables for column layout. 
JB drop "avoid using tables for column layout" and add hyphens to
"line-by-line."
RN how does this impact "colgroup"
PROPOSAL: "Tables. Make line by line reading sensible. Summarize."
DISCUSSION:
?? Why drop "avoid..."
JB It's no longer consistent with 5.5 and 10.3 of the guidelines. That's
not quite what we say anymore. The screen readers caught up more on table
unwrapping.
AC hyphens are missing.
JB Oops!
PROPOSAL: "Tables. Make line-by-line reading sensible. Summarize."
CONSENSUS: "Tables. Make line-by-line reading sensible. Summarize."

10. Check your work. Validate the HTML. Use evaluation tools and text-only
browsers to verify accessibility. 
JB add more incentive for them to go to the source: add "against complete
guidelines" and then the URI for the guidelines following "check your work."
GV need URL to send them back to the guidelines!
HBj good idea to add URL, but why just mention text browsers?
JB because that's all we had room for on the card.
MM add "navigate using mouse only"
HB No. "Mouse only" is no less significant than "voice command only" or
"keyboard only" for navigation.
MM Perhaps further append "If you can't validate with a screen reader, ask
your colleague to play the role of screen reader software and operate with
your eyes closed." 
HB don't add it...
PROPOSAL: "Check work against complete guidelines
www.w3.org/TR/WAI-WEBCONTENT. Validate HTML. Use evaluation tools and
text-only browsers to verify accessibility." [this may not fit...!]
DISCUSSION: 
HB add write clearly.
CMN text-only browsers are as common an evaluation tool as Bobby. But checking
in a few different tools is not a very good test, and checking thoroughly in
different environments is not practical.
PROPOSAL change 10 (validate work) to Validate. Use evaluation tools, WCAG
checklist.
JB Where can we add URI.
PROPOSAL Check your work. www.w3.org/TR/WAI-WEBCONTENT Validate. Use
evaluation tools, WCAG checklist. 
JB Ran out of time. Discussion to continue on EOWG list. Need conclusion by
2:00 p.m. US EDT today.

11. Additions?
HBj Guideline 7 "Ensure user control of time-sensitive content change"
JB There are several guidelines (as opposed to checkpoints) that we don't
get near on the Quick Tips card: color, language, time-sensitivity, interim
solutions, W3C technologies, keep it clear & simple. While these don't all
directly intersect with priority one, some do. Really hard to know where to
start & stop. If we take one phrase off of tables & one off multi-media,
but don't add too much to "check your work" then we _might_ have space for
a short additional item--if we can agree on  which one it is, and agree on
the wording.
PROPOSAL: No additions.
JB: NOTE! We didn't get to this! I don't think there is any more space for
these, but if any comments, speak up quickly!

cW3C (MIT, INRIA, Keio)
[no change]

1999/02
[change to 1999/07]

- Judy
----------
Judy Brewer    jbrewer@w3.org    +1.617.258.9741    http://www.w3.org/WAI
Director, Web Accessibility Initiative (WAI) International Program Office
World Wide Web Consortium (W3C)
MIT/LCS Room NE43-355, 545 Technology Square, Cambridge, MA,  02139,  USA

Received on Friday, 16 July 1999 10:44:16 UTC