10 to 11 AM (Boston Time)
MIT bridge +1 617 258 7910
AGENDA:
1. discussion of AU / ER dependencies
2. ERT document review
PARTICIPANTS
Michael Cooper, MC
Daniel Dardailler, DD
Len Kasday, LK (chair)
William Loughburough, WL
Brian Metheny, BM
Chris Ridpath, CR
Gregory J. Rosmaita, GJR (scribe)
REGRETS
Harvey Bingham
PRE-MEETING DISCUSSION
GJR: CR, could you please add a date stamp to the content of
the ERT?
CR: ok -- I guess that you can't really tell the last
revised date by the version number
LK: well, it is embedded in the URI for "Current Version",
but that isn't readily apparent, I suppose
GJR: plus, as a speech user, I don't normally listen to URIs
as they tend to either be spelled out, or read in a mix of
words, letters, punctuation, and numbers
// MEETING FORMALLY COMMENCES
LK: 2 agenda items:
1) ER/AU dependencies;
2) ERT review;
any other topics?
// no response from group
LK: ok, then, dependencies: has everyone had the opportunity
to review GJR's proposed dependency post? [1] basically, the
dependency is an interface between authoring tools and
online ER tools; there are 2 aspects: the first is the
general idea, independent of whether the ERT is available
online or as a plugin; the second is the question of
implementation: how to create the interface? remotely? as
a plugin? comments?
BM: want to support/permit either; online remotely easier to
implement first; down the road, plugin tools will become
readily available; secondarily, plugins might be the
preferred approach, but it may be worth stating explicitly
that synchronization with an online ERT is more realistic in
the short run
DD: should definitely allow for both, so as to coordinate
production of online tools that do the job, as well as
plugins that do the job; AUGL [2] should allow for both
native implementations of ER and online versions, as not all
AU environments will be online; on the other hand, I do
acknowledge that if you freeze in code of an ERT in an AU
tool, it runs the risk of getting stale
GJR: which is why my response to inquiries about
implementation [3], I stated that if the ERT is prepackaged,
or bundled into, an AU tool, then it needs to have an
"update" feature in order to keep pre-packaged ERT from
becoming outmoded
LK: as far as ER asking AU to put something into the
guidelines, what would it be reasonable to say?
GJR: AUWG is currently looking for narrative techniques for
the AU Techniques document [4] -- since the general
principle of enabling the author to check the accessibility
of the document he or she is creating is already stated in
Guideline 4 of the AUGL [5]
LK: ok, but let's think this through -- if you use an online
tool, you typically feed it the URL of the document you want
to check and the online ERT produces a report; in such a
scenario, the author needs to take the output of the ERT and
change the document source by hand; validation and error
checking plugins to AU tools will often jump you to the
editing point to make the necessary correction or addition,
or at least highlight the errors or missing info -- would we
want to ask that accessibility checking have that degree of
interactivity?
CR: preferably, but it probably needs to be stated as
preference
ACTION GJR: propose Technique in narrative form and
post to ER-IG for review before sending on to AUWG
LK: suppose the ERT is online -- there are many conceivable
ways to make the info it generates available to the author,
such as RDF statements placed into the HTML of the document
being checked -- is that something we want to get into in
our feedback to AU or is that too specific?
MC: we should think about versions of the AU document; such
a scheme could be difficult to implement right away, so
having it in version 1.0 of the AUGL is probably not
helpful, but, if we keep the issue on the AUWG's radar, then
it could be added in a future version of the AUGL
GJR: the AU Techniques document contains sample
implementations, both of existing and hypothetical tools; I
think we need to alert the AU WG that we have techniques, so
that -- at the very least -- the editors can put in
placeholder; note that the AU Techs doc is not in last call,
but that it will probably be used for review purposes during
Last Call (which ends on October 4) and the member review
(PR) stages
LK: are there any RDF mavens on this call who would like to
write some sample implementations?
// NO VOLUNTEERS
LK: one potential problem could stem from multiple
interdependent tags -- can anyone think of a multi-tag
accessibility feature?
GJR: LABEL for forms -- the ID is contained in a FORM
element, while the LABEL text associated with the ID is
marked by the FOR attribute
LK: ah, yes -- so there is a potential problem with FORMs
marked up in TABLE -- how will ERT know what goes with what?
how would you do that in RDF?
BM: existence of label element for "for" should predicate an
"id"
LK: how is it implemented from a UA perspective?
MC: if click on label, the system caret / focus is placed in
associated form element
GJR: if the LABEL is supported by the browser and the screen
reader has a "speak form label" (originally developed to
articulate the labels in dialog boxes) speech users can query
the AT's "speak form label" command -- but, again, it is AT
and UA dependent.
LK: so, are there any volunteers for RDF examples?
// NO VOLUNTEERS
LK: any other thoughts about dependencies between AU and ER?
// NO
AGENDA ITEM 2: ERT REVIEW
LK: any particular area of concern?
CR: MC and I have been discussing some of the items that
could be put on the list for discussion: the checkpoint
covering BLINK and MARQUEE is one that comes to mind -- I
don't have the list we came up with in front of me, but I am
going to post it to the ER-IG list for discussion; we're
going to have to get going on this, as we have a lot of
ground to cover before the 31`October deadline
MC: auto-redirect caught my eye -- need to inform user
before redirect happens, and need to provide means of giving
user the new URI -- tell authors, for example, not use
verbiage such as "You are now being redirected, if your
browser does not support redirection _click here_"
GJR: ERT needs to check value of time delay -- the timing of
the redirect -- should sound a loud alert for 1 or 0 second
redirects
MC: yeah; there should be a certain amount of explanation,
and then that's it; point out that there are better ways to
accommodate users
LK: just because there is a time delay specified in the
HEAD, doesn't mean you're notifying the user; If page comes
on and 10 or 20 seconds later mysteriously changes the user
is still going to be confused
// WL joins
GJR: when I have had occasion to use redirects, I have
always timed how long it takes my screen reader (slowed down
from my normal speed to something that a novice could
understand) to read the redirect message, and then set the
delay accordingly
MC: that's a good idea -- time how long it takes to read the
content of the redirect page out loud to obtain a reasonable
redirect delay
LK: optimally the content of the redirect page should say
"You are about to be redirected."; could put in as manual
technique to give user means of verifying that that info is
being passed to the visitor
MC: should be partially automated to detect redirect and
timing
LK: right -- use that to trigger manual review
MC: something along the lines of "This delay value appears
to be short--does it give sufficient time for the content of
the page to be reviewed?"
LK: are there cases where redirection delays are irrelevant
-- when it is used as, well, what is sort of analogous to
decorative ALT text; here at Temple, people who are inside
firewall see different content than those outside the
firewall
BM: that is usually done through content negotiation, though
WL: what is the justification behind forcing the author to
make the redirect info available?
CR: user can adjust bookmark
WL: browser should maintain database of redirects and
automatically update bookmarks; send it to UA
GJR: a good point, which highlights that this is a
dependency between UA and ER, but if the user is using
a UA that doesn't support automatic redirection, he or she
needs some sort of mechanism to manually redirect the
UA to the new location -- Lynx does this by rendering a
textual equivalent of the redirect as a hypertextualized
URI -- in much the same manner that it treats
FRAMESETs
LK: if webmaster set up with 0 second redirect so nobody
sees content of redirect page--would that be ok? does it
ever happen?
GJR: like as not, in such a scenario there would be no
content on the page to be rendered -- my understanding is
that the redirect is initialized after the doc source has
been completely downloaded, which is why, in some instances,
I can tell when I've been redirected using IE5 courtesy of
the MSIE SoundPack, and even though the UA is busy
downloading the doc source for the new page, JFW will
continue to read the content of the redirect page until the
content of the new page is rendered -- or, at least,
available -- to the screen reader
LK: if the redirect delay is 0, let it stay 0 -- is that a
fair statement?
BM: if allow absolute 0, page content must be blank
LK: if page has no renderable content then it is ok --
should we let them have a title?
GJR: sounds like a GL dependency -- should canvass them for
opinion -- my gut reaction is that not including a TITLE is
a WCAG violation
CR: do screen readers automatically read the URI?
GJR: depends on the screen reader; most do not read the
address/location bar automatically when a page loads,
although older versions of screen readers working with older
browsers may do so; some GUI browsers highlight the address
or location bar upon the first TAB, but it is all quite
browser- and situation-dependent, and even then it is
usually dependent upon the physical placement of the
address/location bar (one of the limitations of the off-
screen model); one usually has to query AT to obtain the URI
MC: this may have implications for GL7 -- in particular, I
have similar feelings about Checkpoint 7.4 which deals with
"Auto-Refresh" -- maybe there is a threshold there where can
be useful feature, but not a distraction
GJR: another UA dependency -- should float it by them when
our ideas coalesce
BM: what is their response time like?
GJR: it is usually pretty good -- at least from the chair;
once the proposal is posted to the UA list, one of us who is
also in the UA WG could ask that it be put on the agenda for
the next UA telecon
BM: sounds good
LK: what is the justification for Checkpoint 3.5A: check
document for header nesting -- first header element must be
H1 and there can only be one H1 in the document
BM: Like way structured now cause can be automatically
checked
LK: do we also want to say that if an H1 it has to be at
top?
BM: there could be a graphic before the header text -- in
general, though, once find an H1, that's it
LK: it's not uncommon to have one big logo image at the top
of a page -- can you have an image inside an H1? if there
is one big logo image, should we demand it be an H1?
BM: rule is to ensure that outline can be created properly;
there are tools that create such outlines
GJR: yes, the W3C Validator, for example [6]
LK: should we insert something to the effect that images
often function visually as H1?
GJR: need to test Mark Novak's Header List PowerTool [7]
to discern if the ALT text from a graphic enclosed in an H1 is
exposed correctly; is the basis for this rule WCAG? I don't
think that the HTML4 Rec forbids more than one H1, but it is
generally considered a bad practice to have more than one H1
in a document, right?
LK: let me check -- yes, in Checkpoint 3.5, and in the WCAG
Techniques document [8] it states that the first header must
be an H1, but nothing explicitly about only one H1 per doc
GJR: we should query GL to ask them what is justification
and whether or not more than one H1 is permissible; from
what I remember of the discussion on the topic back in '97,
one of the reasons for placing H1 at the top and recycling
the TITLE as the content of the H1 was to convey this bit of
metadata to the user--especially users who were using
browsers which didn't make the title readily available to
the user
LK: so what's wrong with a strict nesting order for headers?
WL: strict nesting is bad because it precludes you from
using parallel structures; parallel structures should be
available -- possibly something to raise with HTML and XHTML
groups
LK: when I think of an outline, I think that is natural that
a higher numbered header is the child of the lower numbered
header immediately preceding it -- are you saying that if
the document contains a box with an outline in it and
another box with an outline in it, if both start at same
level then they should be considered equal?
WL: there is no logical reason why header order has to be
spatially defined -- simply listing according to the number
value for the header restricts you to doing it one
restricted way, so that you can't "imagineer" the page
LK: could someone point to something to illustrate this so
it becomes self-evident?
WL/GJR: ok -- we'll try
CR: should we talk more about headings? in particular,
Checkpoint 3.5.B, which covers checking the document for
missing header info; the ERT can look at blocks of text and
suggest that they be made into headings; so if the ERT sees
a paragraph that only has five or 10 words in it and is all
bold, it should suggest that the author make it a heading
GJR: or if there is a brief paragraph or span or div that
used the FONT element or styles to increase the font size /
enlarge text
LK: that reminds me of something I really want to address --
if a stylesheet associates characteristic with an ID -- for
example, an element has ID="apple" and is colored red --
have an attribute not linked to any logical structure, not
linked to strong, not linked to a header -- if putting in
color, has to mean something
CR: ERT doc doesn't deal with StyleSheets at all -- do we
want to start adding StyleSheets to it?
LK: you can do some really screwy things with StyleSheets --
for example, use them inject meaning; as in "important
things are rendered in RED" -- or use color in a document
without linking it to the doc's logical structure; at
minimum want to alert author to that -- "this color you are
using, does it mean something?"
GJR: this is a clear-cut ER/WCAG dependency -- WCAG clearly
forbids exclusive use of font changes to convey information
without a non media dependent equivalent
LK: want to avoid allowing people a loophole -- I fear that
there may be a perception that if one uses StyleSheets, then
everything else is ok
WL: the ERT doc doesn't address the repair and evaluation of
style sheets?
CR: not currently
LK: for purposes of this document, we may not be able to get
to it by deadline, don't have to cover everything in first
release; larger question is should tool be sensitive to such
things?
WL: if violates WCAG, then no go
GJR: brings up an important philosophical point: are we
bound to cover all P1s as currently implemented; perhaps we
need an impact matrix
LK: I'm concerned that authors will stop as soon as they
convert all FONT declarations to StyleSheets, using either
SPAN or STYLE or a mix of both
GJR: AUGL states that most accessible practice should be
most easily implemented, so that when one clicks on the Bold
icon on the toolbar, the AU tool will use stylesheets and
not physical HTML markup
WL: need to discuss this on ER-IG list, as well as with GL,
UA, and AU, but why the overarching cynicism?
LK: it's not cynicism, but realism -- looking at perceived
paths-of-least-resistance: it's not a conscious decision or
thought
BM: yeah -- the problem isn't with people asking themselves
"how can I get around this GL", but thinking "OK, I've used
style sheets, I've taken care of accessibility -- now lets
get on to _real_ work"
MC: speaking of real work, our time has expired
LK: ok, but before we adjourn, I want to discuss the timing
of our next meeting;
following in pattern the next meeting should be on October
12, but I can't make it
GJR: also date of UA face2face in Redmond
CR: according to my calendar, the next meeting is slated for
October 19, 1999
WL: can we send the notice on the 18th and not the 19th?
MC: how about sending out the reminder notice on the 15th!
LK: I sent notice yesterday, but -- by mistake -- to the
wrong list; I promise to be more careful in the future
// meeting adjourned
References
1. http://lists.w3.org/Archives/Public/w3c-wai-er-ig/1999Sep/0030.html
2. http://www.w3.org/TR/1999/WAI-AUTOOLS-19990903/
3. http://lists.w3.org/Archives/Public/w3c-wai-er-ig/1999Sep/0033.html
4. http://www.w3.org/TR/1999/WAI-AUTOOLS-TECHS-19990903/
5. http://www.w3.org/TR/1999/WAI-AUTOOLS-19990903/#gl-identify-markup
6. http://validator.w3.org/
7. http://trace.wisc.edu/world/computer_access/headers_ptoy/headers-pt.zip
8. http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-logical-headings