- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 21 Sep 2000 16:28:44 -0400
- To: w3c-wai-ua@w3.org
21 September 2000 UA Guidelines Teleconference
Present:
Jon Gunderson (Chair)
Ian Jacobs (Chair)
Jim Allan
Gregory Rosmaita
Eric Hansen
Rich Schwerdtfeger
Harvey Bingham
Tim Lacy
Charles McCathieNevile
Mickey Quenzer
Absent:
David Poehlman
Regrets
Kitch Barnicle
Next meetings:
Tuesday, 26 September (extra, 13:30 - 14:30 ET)
Regrets for 26th: KB, HB, JA, TL (for half).
Thursday, 28 September (regular)
Agenda:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0403.html
Minutes of previous meeting 14 September:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0400.html
Review Action Items (see details below)
Announcements
1.Extra teleconference scheduled for Tuesday 26 September 2000 at
1:30-2:30 EST USA
2.Face-to-face meeting update
IJ: No update now since Judy Brewer in White House event today.
I will follow up next week.
Discussion
2.Issue 311: UAAG 1.0 and DOM Level 2 as UAAG 1.0 moves towards last
call
http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#311
IJ summarizes DOM status, relation to UA status.
Q: Is there any need to change the document?
CMN: I propose that we remain in the status of tracking it.
RS: I wouldn't want to limit 5.1 to read-only. We do some tagging
to increase performance.
Action RS: Talk to people at IBM about sending techniques for
performance-enhancing techniques (and whether proprietary).
JG: You can always to more.
RS: Adding an event listener is like modifying the DOM. It's like
modifying the DOM (extended API). E.g., if you have a dynamic
document, you can listen to mutation events. Not necessarily a UI
change. Is adding an event listener considered a change to the
DOM? We are not changing DOM nodes.
JG: You could use the DOM 2 event model in 5.5. If we added, then
that might be part of a requirement for 5.5.
JG: Do we have implementation experience for the event model?
RS: I don't think so.
JG: I'm concerned about making DOM 2 event module a
minimum requirement if we don't have implementation experience,
notably to AT vendors who have not used it.
CMN: Our expectation today is that DOM will not change much
as it goes to Rec. We are specifying our requirements based on
that assumption. If there are dramatic changes, we will revisit
our requirements.
IJ: I believe we've already discussed changing priority of 5.7
(and decided not to) and also decided not to add additional
requirements.
RS: Making 5.5 with DOM event model a P1 probably not reasonable
at this point. I'm ok with 5.5 as is. Could add a P2 requirement
for DOM 2 event model.
CMN: I think that the guidelines should set a target for
developers. I would be unhappy about changing the priority level
based on implementation levels today.
IJ: Problem that people don't love all of the events module. And
you can't claim conformance to part of the module.
Resolved:
- Leave current checkpoints: Consensus.
- Don't add any other DOM Level 2 requirements.
1.Issue 316: Using the DOM to make available information on user
agent
generated content
http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#316
Q: Is there a requirement that generated content be part of the
DOM (and thus available to the AT)?
Examples:
- Bad markup
- Configuration
- Missing resources
GR: What JFW does today (with COM/DOM) is give the user the
choice of ignoring graphics without alt text, reading the end of
the URI, or the alt information if present.
JG: I'm not sure that having the mainstream user agent put repair
content in the DOM is a good idea. We decided to make available
info the DOM because different renderings have different
requirements. A problem is that the AT user would not know what
comes from the author and what doesn't.
MQ: I think we should suggest, but not require inclusion of
generated content in the DOM.
GR: What HPR and PwWebSpeak do points the way for what mainstream
UAs should do: allow the user to configure how much information
should be provided by the UA.
RS: One problem - suppose that the AT is depending on what's
presented graphically, in addition to the DOM. If they are not
in sync, could be problem.
IJ: I think the document needs to say clearly that we are building
the UAAG 1.0 based on assumptions about the DOM. And we are not
requiring that UA's do things based on screen scraping.
GR: Issues:
- Effort
- Consistency
- Origin
RS: I think that if the UA repairs invalid markup, then the
this should be represented by the UA. For example, form control
that are outside the FORM element.
IJ: It's legal to put form controls outside a FORM element.
TL: We repair incomplete tables.
IJ: Repair is non-standard. I have a problem requiring
passing non-standard content through APIs to ATs. It could be
useful, but no guarantee that that will benefit accessibility.
Right now, we are not making requirements about the construction
of the DOM (in fact, we have intentionally said "we don't know
where it comes from: style sheets, markup, configuration, repair,
etc.).
CMN: I would argue that if the user agent changes the DOM, it
should alert the user.
IJ: I think most users would prefer not to be told and instead
just want the UAs to fix stuff silently.
CMN: I think that some changes made during parsing don't need to
lead to notification. But where you add content, you should
tell the user and also put it in the DOM. The fact that the
document has been changed on load is available.
RS: I don't think that's useful.
CMN: Why it's useful: I want to know whether the UA has made
a change as opposed to a change from the author.
RS: I think that the only reason you need a mutation event is
if you give it to the AT, then change it. But changes before
making available to the AT don't need to be told to AT.
IJ: I, as a user without a disability, have no idea that my
user agent has fixed content.
RS: And I have no control over how IE does its repairs.
IJ: Lots and lots of information can change from UA to UA based
on author changes, configuration changes, repair differences
(which are not standard), content negotiation, etc.
JG Summarizing:
- UAs do repair all the time.
- The only explicit repairs we require are 2.5 and 2.7
- Issue of whether user needs to know or wants to know which
repairs have been made.
EH: Is this part of the discussion about 1.5 (non-text messages)?
IJ: 1.5 is not about content but about UA's native UI.
EH: I have a suggestion: A checkpoint that requires the developer
to document any information that is likely to go to the user
interface but that may not be reflected in the DOM. I'm thinking
about six classes of information:
Information reflected in the DOM? (yes/no)
What kind of notification is required (none, in the moment, on
inspection)
EH: The UA developer would have to document which information
they're going to repair without notification (i.e., silently).
Or, some information will be rendered, but no notification, and
not in DOM.
RS: You don't always know what will end up being
displayed. Notably when you put style sheets in the mix. Also,
some repair techniques.
IJ: Proposed: Add a statement to the document that says:
Developers may put repair content in the DOM, but are not required
to by this document.
RS: There are better techniques for repairing alt text.
IJ: 2.5 expresses the minimal requirement.
RS: I'm saying that if a UA does the job, it should be in the DOM.
Why is that unreasonable?
CMN: I agree with RS - the overhead of putting it in the DOM.
I would go back to the suggestion that if you put it in the DOM,
you notify the AT. Reason: if you build an AT, then you might
do even more than what the mainstream UA.
RS: If a UA does repair, it should be reflected in the DOM.
JG: How does AT know that there's been generated alt? It can't get
that information through the DOM.
CMN: Hence firing the mutation events.
JG: You don't know who changed the node. It could be a script.
CMN: Now I'm thinking that this is not a requirement. The minimum
requirement for change is trivial. I expect that better UAs will
provide better techniques, and ATs will provide even better ones.
It's more a point of distinction than a requirement.
GR: The user doesn't care where the information came from, but
must have confidence that the AT is doing the right thing.
CMN: It's more useful for the AT to be able to tell the user:
a) There's no alt text b) there's generated alt text c) there's
author-supplied alt text.
CMN: So my preference is to not put it in the DOM or put it in
with a mutation event.
IJ Proposal for 2.5:
- If you put repair text in the DOM, notify the user.
IJ: But I don't know how this is this done.
CMN: I would like to see a recommendation that repair content
be put in the DOM and that if this is done, that there is
notification.
RS: If the UA does more than minreqs for 2.5, then include
in the DOM. But I don't know how you would use the event
model to indicate which element caused the change.
RS: The DOM implies structure to the document. Repairs that
change the structure need to be part of the DOM.
GR: I think this should be talked about in prose.
Resolved:
- Don't add any requirements to the document.
- Add prose to the document summarizing all of this discussion
(to 3.9 in Techniques).
Action IJ: Draw up text to this effect.
Open Action Items
1.GR: Proposed repair checkpoints
2.KB: Submit technique on providing information on current item and
number of items in search
Completed Action Items
3.CMN: Propose rewording of checkpoint 7.6
Done:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0404.html
Refer also to JG proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0405.html
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Thursday, 21 September 2000 16:28:45 UTC