Pre-Agenda Items
1) Posts About ERT Being Sent to
DD: some messages being posted only to ER-WG and not to ER-IG
LK: aren't they the same thing?
DD: not exactly: WG gets IG, but IG doesn't get WG
LK: will be more careful myself, and will try to stress importance of posting to IG list whenever opportunity arises
2) Report Form/Tool WL: what is status of report mechanism? still in beta?
DD: yes
WL: should get to EO people to publicize the same way they are pushing Quick Cards
GJR: will URI of report form be added to future iterations of QuickTips card?
DD: QuickTips intended more as assistance for individual authors, not for evaluators
GJR: there is overlap; a lot of people who ask for the QuickTip cards do so in order to become familiar with the terminology so that they can conduct a meaningful and fruitful dialog with a webmaster or site maintainer
HB: QuckTips has a reference to the WAI home page; I expect the WAI home page to highlight the report form
WL: GJR is right--when I attend disability rights conventions/conferences; the attendees may not be interested in writing their own web pages, but they have a definite interest in why things don't work -- why they can't buy shoes or something online; need to know the issues before complaining about inaccessibility of an ecommerce site
LK: since QuickTips already has a pointer to WAI home, if get report form at top of page, then the QuickTips will be funneling people towards it;
WL: problem with WAI pages is that they are targeted towards quote people who are able to or want to do technical stuff unquote; WAI home highlights WCAG, but fails to address the simpler level complaints: namely, quote I can't use this site because dot dot dot unquote;
GJR: in most instances, the person encountering difficulty with a page has no idea what is the cause of the difficulty, only that he or she can't use the page in question; not everyone is inclined to take a look at the document source in order to figure out what the page's author intended, nor should they have to do so, but they do need a frame of reference, and there are certain symptoms that point to certain problems; moreover, we don't yet know all of the accessibility barriers that exist, and so problem reports may highlight or bring to the surface difficulties, incompatibilities, and accessibility issues that may not have already been raised
// MEETING FORMALLY BEGINS
ITEM 1: Report Form Update / Comments LK: first item is the report form: the way report form is formulated now is especially good if you have a good understanding of what is going on on the page being reported- -need to have understanding of techniques; a lot more people who can report problems than can diagnose them; what about a blind individual who doesn't know what is going on? is there anything we can do to assist that? Gregory, what sorts of problems do people report?
GJR: When beginner approaches you they might say they went to site and were able to access a list of navigation links, but when they selected a link nothing would happen. This usually means they are in frames, the change was in another frame, and they couldn't tell what happened. There are also times when unexpected things happen, like when making a form selection takes you to a new page without the user explicitly asking. So user gets disoriented.
LK: there seems to be a clear cut need for a list of symptoms and possible causes, such as appears in any technical reference on trouble shooting documentation--if X happens, then it may be due to Y;: we've already identified a few main problems: 1) click but nothing happens (point-of-regard/focus stuck in navigation frame); 2) select link, viewport which is updated is voiced or enlarged by AT, but point-of-regard/focus remains in navigation frame; 3) new window spawns without warning and user attempting to use back button / mechanism becomes frustrated and may conclude that the UA has malfunctioned, when it has only spawned a new window (AT needs at least to know that a new window has spawned so that it can pass information to user) 4) select and too much happens (event handled forms; needs to be able to keep track of changes from browser window to browser window, etc.)
MC: any progress getting Lynx to handle these situations.
GJR: lynx can handle forms but no support for javascriptingmichael; any progress in getting lynxs to handle.
greg. but lynx assumes event handled form assumes certain forms, but no support for javascripting. Lynx can keep up with media, frames, helper apps, but limitations not addressed be cause user agent can't assume saft thing happens
MC: could inform you page was loaded but could tell you
MJR; with lynx frame problem less large cause it lists frames and uses uri or name, e.g. main, nav,
LK: are these all obvious violations?
MJR Good part already covered. Some may be covered more general terms. Some may require more in techniques document.
WL: what about autosubmission on enter?
MJR: iif you inadvertantly hit enter button forms get submitted. ua guidelines say get confirmation
Also, layout of forms can cause problem. Most layout for search forms done thru formatting, type in query, next thing is submit not realizing that there are more options after submit, to get full form and more full form. So you don't know there are other options.
Especially in metacrawler, on advance form text, submit, checkboxes for limiting etc, how long to wait
they never get to advanced features.
Best way to handle is describe form , e.g. how many options below the submit. e.g. rfb&d wanted redundant submit and reset, so had at top of page, and at bottom of form.
LK: they don't know what they are missing.
GJR: not uncommon , especially in JavaScript, to populate status line, messages scroll on status line. e.g. "today only no shipping or taxes." E commerce want to get as much info as possible on screen. so give as much as possible at first glance. So use cut corner like status bar.
Could have a repair tool for guideline 9, to make available a list of all form controls available, using html 4 semantic information, grouped, sort of like header lists in Trace's power tools, like a tree outline, by header level. Can check if organized correctly. Can give a list of headers.
GJR: Could have following repair tool: configured for guideline 9, help user, make available list of all form controls available, using html 4 semantic info, grouped, sort of like header list does in traces power tools. List could be, like tree outline, by header level. Could check if organized correctly, list access keys. Could list in tab order. This requires HTML markup however.
Allaire Homesite 4.0 is good for serious user in this regard. When you ask to insert a form element it pops up a property sheet. Most sheets have title, anchor, longdesc, alttag, access keys, tabindex. It's helpful that a company is doing that already.
However there is a major problem for blind users is lack of system carat and system carat controls. Requires use of mouse. Still it creates good content.
LK: the second item I want to address is the bottom line rating -- the due date for it is the end of the month; I made a recommendation on list; want to see if we have consensus; proposal on bottom line rating is as follows:
give bottom line rating A, double-A, or triple-A, in accordance with WCAG definitions, but set up the tool to force people to make an explicit affirmation that they have performed the manual checks; for example, in ERT, there are a number of automatic checks and a number of manual checks, so instead of saying you are A or double-A or triple-A approved when the automated checks are completed, it says "Your page has received a preliminary rating of [rating level]; to confirm this evaluation, please perform the following manual checks", and for each manual check, the user has to check a checkbox to affirm that he or she has performed the manual check and that he or she believes that the page complies; after completing manual checks, and a subsequent check to ensure that any information added or subtracted during the manual checking is valid from a markup perspective, the tool then issues a conformance rating;
so, in summation: if auto check says :inaccessible", then the page is inaccessible, and the user follows the automated prompts to correct the automatically verifiable checkpoints; if passes automated check, the tool will say "this page might be accessible; it might be [insert level of compliance obtained from automated check] but before a compliance rating can be issued, you need to perform the following checks:", and for each manual check there is a checkbox or radio button that says "I have completed the manual check for this checkpoint and have fixed any errors"
WL: Bobby already does that
LK: not exactly -- Bobby (at least the last time I used it) told me "Congratulations! Your page is accessible and earned 3 stars" and THEN it gives you the list of manual checks to perform -- what I want is a mechanism which forces the author to tell the software that he or she has conducted the manual check and fixed any errors BEFORE moving on to next manual check and before the issuance of any conformance rating
WL: still operating on the honor system
GJR: but you have to check off that you have performed the check, so it is easier to ascertain whether or not the conformance claim is valid or bogus; in other words, you have to actively lie, rather than passively ignore or overlook the manual checks; with LK's methodology, authors have to explicitly say "I did check" rather than simply grabbing the icon and never getting 'round to the manual checks
WL: what about email address as a signature?
LK: for accountability's sake?
WL: yes, it would determine to whom you send the conformance logo -- that would prevent people from simply downloading it and pasting it on their pages without first having performed the evaluation and repair
LK: so it would work like a digital signature?
WL: yes; it signifies that the author has not only claimed conformance, but that he or she is known to have performed (or at least claimed to have performed) a discrete and verifiable group of evaluation checks -- not that each claim would be verified, but if someone was going to perform an eval of that page, they'd have a basis upon which to build, plus a mechanism for distinguishing bogus claims from valid claims
MC: would the email come from WAI or from the tool -- BOBBY or A-Prompt?
WL: both or either; no condition WAI has that you have to go through Bobby to get WCAG logo
MC: I'll admit that I'm a bit little scared about us taking on the overhead of having to process those emails
LK: what if tool requires that you put in an email address, then tool sends off notification of email address, stating that such-and-such page is showing rating logo X and that your (that is, the developer of the evaluation tool's) name is on the line
WL: MC, I'm not sure what you mean by overhead
MC: the amount of data we would have to store on server and the processing cycles
WL: no -- you'd just send the logo back to them; as a means of showing that the author has verified that he or she has taken a defined set of steps to ensure the accessibility of the page or site
MC: for the online version, I can see that working ok, but I think something different is needed for the offline version; sort of an advanced feature -- if attempt to claim approval, need to go through procedure, if just curious or if checking a page in development, then you can get a preliminary report without submitting email address
WL: sounds reasonable
LK: require that email address be on the form and explicitly label it with RTF notation or whatever, so that evaluation tool checks to see that that is a valid email address?
WL: biggest problem in reporting accessibility problems is figuring out quote who to complain to unquote
LK: could suggest to WCAG that this becomes new requirement for WCAG; all pages must have an address to which problems and bugs can be reported
BM: as a condition for using the approval seal? for claiming approval?
LK: suggest that addressing responsibility be part of WCAG - - could simply state that in order to be considered accessible, a page must have a clearly defined and addressable complaint address -- would give a P1 myself
GJR: P1 for me, too
DD: putting META data in page a WCAG requirement
WL: yes, but the types of META data isn't specified
DD: no, doesn't say which is required; something which needs to be fleshed out and addressed in the WCAG Techniques document
MC: are we talking about putting META data on page itself or in database stored at W3C?
DD: to be WCAG compliant would have to have in the page itself an indication of where to complain; way to implement is by using well-known META data keywords; is a P2 right now, but, yes, the current techniques have much room for improvement
GJR: so we could suggest that authors be encouraged to use the < META NAME="author" and include an email address for the person responsible for the upkeep of the page in the CONTENT for that META comment?
DD: yes,
GJR: what about LINK HREF=mailto which Lynx has recognized for years
DD: how does that work?
GJR: Lynx uses the LINK element (if present) in the HEAD to obtain a quote comment unquote address (which you invoke by typing the letter c) through which comments on the page can be addressed to the maintainer of the page -- if isn't present, it guesses at an address, using the formula webmaster at sign w w w dot domain name dot extension -- I'd prefer it to look within the ADDRESS to try to obtain a valid email address before prompting for webmaster at domain, because at least four-fifths of the time, that formula fails, so if a "send a comment" mechanism is going to be supported by a UA or any other application such as an eval tool or repair tool, I'd suggest that it look first for an email address in the LINK element; second, that it look for and that authors be encouraged slash required to define an email address as well as the name of the author in the CONTENT portion of the META comment; and that third, it check the ADDRESS for a text string with an at-sign which isn't bounded by white-space
DD: yeah, the META comment that refers to the page's author would have to have an email address
WL: needs to be in there, then so validator can report lack as error
BM: so, what's needed is a content tag and a conformance tag? would it make sense to have 3 flavors of this checkpoint? if claiming single A, then it is P1, if claiming double-A, then it is P2, and if claiming triple-A, then is P3; need to define common tag that UAs can recognize conformance claims
GJR: something similar to a PICS rating?
BM: sort of
DD: I've mapped WCAG compliant ratings to PICS, but can't think of a pointer off the top of my head right now; basically, inside PICS there is room for defining the author of the PICS claim -- the person who has done the rating; someone using the WCAG can use PICS to claim a specific conformance level and identify himself; my question is, are we talking about a different and simpler thing that just has a way for anyone looking at a page to access info about the person responsible for page; because the maintainer of the page may not be same person as the author of the page content; what are the reserved keywords that people should use?
AGENDA ITEM 3: Formal Last Call Review of AUGL by ER LK: AU has formally asked ER to review the Authoring Tool Guidelines; using the draft located at: http://www.w3.org/TR/1999/WAI-AUTOOLS-19990903 should I make good faith effort to summarize the individual reactions of ER members in a formal report to the AU WG?
// unminuted explanation of UA process by GJR (scribe)
LK: DD, correct me if I am wrong, but it is my understanding that we weren't asked to only address dependencies but were being asked to review the AUGL period;
DD: to ask chair of other WGs for dependency review is normal process; have we any stated dependencies?
LK: well there are many obvious points of overlap; but it has been suggested that the entire ERT document, once it becomes finalized, be subsumed into AU techniques document
WL: require page to must give email to claim accessibility.
GJR: could put in metadata. with Ask WCAG?
go to wcag say need complaint address; metadata require that it be part of wcag
LK: so, it comes down to whether or not the summary that I will sending to AU will consist just of dependencies
GJR: separate out dependencies from your summary and circulate the list of dependencies that you discern to list so as to elicit feedback from ER, before sending them to AU as chair of ER: then send all of your other comments on to AU as Len Kasday, private citizen of cyberspace
LK: OK; do we also want to express our expressions of concern on our list? I think yes, so as to stir up discussion; I don't know why, but I'm still inclined to summarize all of the comments and issues that arise from ER reviews of the AUGL
HB: how many have already submitted comments to AU? of those who haven't who would prefer to submit comments as an individual and who would prefer to go through LK?
WL: those of us who are also active participants in the AU WG are bound to submit comments
HB: I'm not a quote active unquote member inasmuch as I don't attend the AU telecons, but I do monitor the AU list, and have submitted my comments to the WG
LK: I suppose it would be strange for AU members in ER to submit comments to their WG through the chair of another WG!
RESOLVED: LK will submit formal ER report on AUGL -- formal report will focus exclusively on dependencies; dependencies will be discussed on ER list pending posting of dependencies by LK
GJR: make sure to note in the intro that members are highly recommended to review the AU GL in its entirety before reviewing your list of dependencies, and that they are urged to address any issues or concerns arising out of their review which are not listed as dependencies directly to
LK: sounds reasonable
WL: next meeting?
LK: 28 September; same time same place; info already posted on ER web space
BM: more review of ERT document needs to be on agenda
GJR: are meetings going to continue every other week on same schedule?
LK: may not be able to make a meeting 12 October meeting;
GJR: would present a problem for those traveling to and from UA face2face in Redmond
LK: what about 5 October?
DD: I will be in Boston at that time for a series of meetings
LK: how about 19 October?
RESOLVED:: next meetings: Tuesday 28 September 1999 at 10am (Boston time) Tuesday 19 October 1999 at 10am (Boston time) Phone bridges for each to be announced.
LK: do you want to spend additional time on this call to discuss some of the outstanding issues or take it to the list? are people available for an additional half hour? can we go to 11:30?
RESOLVED: extend discussion to 11:30 AM
ITEM 4: ERT Review
MC: BM mentioned he wanted to discuss 7.1.A -- no arguments on that, right? the markup it addresses comprises deprecated elements, MARQUEE and BLINK
HB: want to address statistics cited re: potential screen flicker -- hertz cycles different in Europe than North America -- needs to be addressed; some displays used here are synchronized to the power frequency -- is that true in Europe?
WL: are you suggesting that we say it's better to go to 49 than 50?
HB: yes
LK: right now 7.1.A. doesn't say anything about Hertz
// unminuted dispute over which ERT draft under discussion
HB: reference document [WCAG] does address hertz rates, so I suppose that this is a coordination issue with WCAG
LK: are you suggesting that they lower flicker rate requirements to 49.9 Hertz?
HB: yes
LK: don't see point of having frequency in there -- besides, at that frequency, the flicker would be indistinguishable
GJR: visually, perhaps, but flickering or blinking content may be repeated ad nauseam by AT even if, visually, the content appears stable
LK: what about saying no flickering period;
WL: if mention frequency, should go down to 49, but probably shouldn't mention a number at all, because it is a silver platter being handed to someone who wants to abuse or avoid this req and still claim compliance
LK: ok, so there are 2 comments to be funneled to WCAG: comment 1) if listing hertz, figure cited must be less than 50 hertz; comment 2) why have frequency at all?
HB: a test file for blink rates might be useful
LK: I'm personally concerned about the possibility of false alarms arising out of GL7 in regards applet, object, script, or embed
HB: isn't there an attrribute can be used to define the duration of an embedded event, like the playing of an audio file?
LK: anyone could write an applet with a hard-coded blink rate; in principle could have software that test blinking by running various objects by taking timed screen shots and determining if different
WL: but object has to change and then change back to be a flicker: screen A, screen B, blank screen, repeat
LK: flicker implies continuous flicker; if just flashes, should we let it go by?
// DD leaves for another meeting
WL: just tell 'em avoid flickering; getting into detail is to tempt them to find a loophole
BM: or define as rapidly changing image
LK: asks for each is it blinking?
WL: now that does violate the "cry wolf" principle!
LK: especially if embedding a MIDI file
GJR: It's a problem if midi or audio is automatically played because it interferes with speech. So need to check for embedded audio, e.g. .mid, .wav, .au
LK: does WCAG know about these issues?
GJR: in the techniques document, but not exhaustively, and not (in my opinion) sufficiently -- UAGL does address the issue: a conformant UA needs to have mechanism to shut off / stop playback of embedded audio files
LK: can you tell if can you can shut it up from the document source?
GJR: no, playback is browser specific, and varies greatly even from release to release in most instances -- and even where the embedded audio file is not defined to loop, embedded audio may continuously loop
LK: needs a discrete checkpoint
HB: does the audio file need to be embedded in HEAD via LINK?
GJR: most of the audio files are encoded using the deprecated proprietary EMBED element, and not OBJECT
WL: depends on browser; if embedded in BODY some will play it others won't
HB: ok, may be a red herring
WL: what about looking for common extensions?
GJR: are range of common extensions-- .mid, .wav, .au
LK: reached 90 minute mark; let's continue this discussion on-list; at the next meeting these and similar concerns will be pushed to the top -- please post concerns about what is missing or what needs to be further defined in the ERT to the list
// meeting ends