- From: Ian B. Jacobs <ij@w3.org>
- Date: Thu, 25 Apr 2002 16:55:52 -0400
- To: w3c-wai-ua@w3.org
UAWG teleconference, 25 Apr 2002
Agenda announcement:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0059
Participants: Jon Gunderson (Chair), Ian Jacobs (Scribe), Eric
Hansen, Tim Lacy, Jim Allan, David Poehlman, Harvey Bingham,
Rich Schwerdtfeger
Previous meeting: 18 April 2002
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0056
Next meeting: 2 May, 2pm ET.
Regrets: IJ, RS
Reference document 12 September Candidate Recommendation:
http://www.w3.org/TR/2001/CR-UAAG10-20010912/
==========
Discussion
==========
Action IJ: Update issues list.
1. Sun BeiJing Accessibility Team
a) JG, Judy, IJ will talk offline with them first.
b) Based on that discussion, talk about possibly rescheduling
our weekly meetings.
c) Additional meetings for test materials?
JG: Does the current time still work for people as the summer
is approaching?
(No problems for people.)
2. AT requirements/ DOM
JG: Postponed for now while we collect more information.
Action JG: Contact AT developers to get them to send
more requirements.
3. Issues list
http://www.w3.org/WAI/UA/issues/issues-linear-cr2.html
=========
Issue 521: If not required to conform for all implemented
formats, what is relation to "turn off all images", etc.?
=========
Issue 522: Make clearer early in conformance section that ok to
conform to fewer than all checkpoints.
Resolved: Accept this proposal.
=========
Issue 523: 2.10: Explanation of placeholder requirement unclear
Resolved: Change 2.10: "If the user agent has satisfied
checkpoint 2.3 by using a placeholder, then allow the user to
toggle rendering between the placeholder and the original
author-supplied content."
=========
Issue 525: 1.2, 9.5, 9.6: Can satisfy these checkpoint on per
event type basis (not handler)?
Resolved: Clarify in 1.2, 9.5, 9.6 that sufficient to address
handlers on a per event-type basis.
=========
Issue 526: 6.3: Checkpoint title says "content" but checkpoint
text refers to "markup". What is intended scope?
Q: Do 6.1/6.3 include access to all bits? Or just limited
to markup language info (e.g., terms of infoset)?
IJ: Should we think about 6.1 in terms of infoset requirements?
That seems useful to me: distinguishing stuff from API
requirements.
/* JG leaves */
IJ: Talking about infoset seems to clarify what's expected. What
would PDF look like? What about plain text? What about style
sheets?
IJ: What about "structured formats" (I hesitate)?
TL: I suggest avoiding "markup".
IJ: Should we require in Guideline 6 access to all (plain) text
content? This would be consistent with 2.2. Or should we just
expect that everyone can do HTTP GET?
RS: In the case of IE for text files, IE takes this content,
converts to an HTML document that has a big PRE statement...
RS: There are issues with secure sockets; some ATs may not be
able to use HTTP GET to get at text content.
IJ: Question for 6.3: does this assume STRUCTURED access to
content? Or does a dump of content suffice?
/* EH leaves */
IJ: Proposed for 6.3.1:
"For content other than HTML and XML, provide structured
programmatic read access.
Note: In the case of plain text, the structured access
will only be as structured as the text content."
Consider three ways of using CSS:
a) Processed as text/css (i.e., according to the CSS spec);
in this case it can be processed and discarded. Not in
content (i.e., object).
b) Processed as structured CSS (e.g., and authoring tool).
In this case, you want structured access through an API.
c) Treated like text/plain. In this case, the API access
would only be as structured as the plain text itself.
[Same idea with schemas, for example.]
TL: This is how we treat CSS today. E.g., you can view
CSS in Notepad today (handed off by IE).
Proposed: Change 6.3.1:
"For content other than HTML and XML, provide
programmatic read access according to the structure
of the content."
DP: Would Adobe say that there's enough info in a PDF
file to allow for that to be provided?
IJ: See Acrobat core API:
http://partners.adobe.com/asn/developer/acrosdk/docs/coreapi/CoreAPIReference.pdf
IJ: I think the proposal addresses:
a) Need for structured access.
b) Plain text case handled (API will be minimal)
c) I think by using "content" we are ok with cases where style
sheets, DTDs, etc. not maintained in document objection.
Resolved: Change 6.3.1:
"For content other than HTML and XML, provide
programmatic read access according to the structure
of the content."
==================
Open Action items:
==================
IJ: Send proposal for Guideline 10 modifications based on
4 April 2002 teleconference
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0027
IJ: Propose text to the UAWG on conformance profiles for use by
other specifcations.
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0027
IJ: Review UAAG 1.0 for which checkpoints should be "all formats"
v. "formats that are part of the claim". (issue 521).
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0049
JG: Write up user scenarios for why non-text-based highlighting
important for users; notably which users.
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0027
See for additional questions:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0029
JG: Clarify why "Max rating" used in some cases (in low implementation
experience section) and "Avg rating" in some cases. Also, delete "+/-"
with P (round down from G to P)
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0049
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Thursday, 25 April 2002 16:56:36 UTC