W3C logo Web  Accessibility Initiative (WAI) logo

Evaluation & Repair Interest Group Teleconference
Tuesday 28 September 1999

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


Copyright    1997 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.