- From: Jon Gunderson <jongund@uiuc.edu>
- Date: Wed, 13 Mar 2002 14:30:35 -0600
- To: w3c-wai-ua@w3.org
>Date: Wed, 13 Mar 2002 14:26:46 -0600
>To: "Ian B. Jacobs" <ij@w3.org>
>From: Jon Gunderson <jongund@uiuc.edu>
>Subject: Re: Issues and comments arising from UA evaluations
>
>Responses in JRG:
>At 03:26 PM 3/12/2002 -0500, you wrote:
>>Dear UAWG,
>>
>>A number of issues about the UAAG 1.0 Candidate Recommendation
>>[1] have come up during recent reviews with developers. Most
>>of these issues only require clarification. However, there are a
>>couple of proposals for more substantial changes below that
>>I'd like to discuss at an upcoming teleconference.
>>
>>Jon, I don't suggest that we add these to the issues list until
>>the UAWG has had a chance to discuss them.
>>
>>Comments welcome,
>>
>> - Ian
>>
>>[1] http://www.w3.org/TR/2001/CR-UAAG10-20010912/
>>
>>=============
>> From the Mozilla review:
>>
>> 1) Can checkpoints 6.1 and 6.2 be satisfied if the
>> APIs are not available out-of-process?
>>
>> Proposed: Yes.
>
>JRG: I agree, in or out of process access relates to Checkpoint 6.9
>
>>=============
>> From the (incomplete) RealNetworks review:
>>
>> 2) Add a section to the document explaining how other
>> specifications can create profiles of UAAG 1.0
>> conformance. For instance, if the FOO specification wants to
>> require FOO user agents to conform to UAAG 1.0 in a
>> particular manner, what should/must the FOO spec say?
>>
>> Proposed: I would like to write this up and send to the
>> UAWG in the near future.
>
>JRG: I think this is good, but I think it would be good to work with
>another working group trying to do this as part of the process.
>
>> 3) UAAG 1.0 needs to be clearer about the fact that a user
>> agent is not required to satisfy all requirements for
>> all implemented formats. I believe the document already
>> says this, but it's not easy to find.
>
>JRG: Editorial
>
>> 4) Make clearer up front (e.g., at the beginning of section
>> 2, not just the conformance section) that a user agent
>> can conform to fewer than all the checkpoints.
>
>JRG: Editorial
>
>>=============
>> From the Opera review:
>>
>> 5) Checkpoint 2.10 needs clarification. Current text:
>>
>> "Once the user has viewed the original author-supplied
>> content associated with a placeholder, allow the user to turn
>> off the rendering of the author-supplied content."
>>
>> Proposed:
>>
>> "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."
>
>JRG: Sounds good to me
>
>> 6) Checkpoint 3.1: Clarify that if the user agent allows the
>> user to turn off all images, including background images,
>> then this checkpoint is satisfied, but this is not
>> the optimal solution (since better to be able to turn
>> of background images separately).
>
>JRG: OK with me
>
>> 7) Clarify for 1.2, 9.5, 9.6 that checkpoint may be
>> satisfied on a per event type basis; additional
>> granularity (per handler) is not required. This
>> clarification is consistent with our recent
>> DOM discussions.
>
>JRG: I agree, we only want to trigger user interface events. If more than
>one event handler is associated with a user interface event, then all of
>them should be triggered.
>
>> 8) Checkpoint 6.3: The title is "Programmatic
>> access to non-HTML/XML content", but the first
>> requirement refers to "markup language" (which would
>> exclude, for example, images). Do we intend "all content"
>> here, or just markup (non-HTML/XML) markup languages?
>
>JRG: I think we want the more general term, for example we want to include
>things like PDF and FLASH. FLASH is markup oriented, but I don't think PDF is.
>
>> I don't have a proposal for this one.
>>
>> 9) [Editorial] Clarify in 3.6 why P2 and 3.5 is P1.
>> This is already in the techniques doc, so not critical.
>
>JRG: OK
>
>>10) Checkpoints 6.2 and 6.3 (DOM write access and
>> programmatic access to other types of content):
>> there is some content where it's a security issue
>> to provide *any* kind of programmatic access. [Tantek
>> made similar comments during the Mac IE review.]
>>
>> Some ideas for dealing with this:
>>
>> a) Provide programmatic access, but when security
>> is an issue, prompt the user for confirmation
>> (on configuration).
>>
>> b) If the user agent has a mechanism for allowing trusted
>> programmatic access, then ATs should use this mechanism,
>> and the UA must make available all content to these
>> trusted agents.
>
>JRG: We have pretty limited write access requirement. In forms it is
>primarily to the value attribute with only the allowed values defined by
>the author, since this is all any user gets to modify in the form. We
>don't allow the user to add nodes or change the type of control, becasue
>the user does't.
>
>>11) Checkpoints 6.1/6.2: Is it a P1 to implement some API
>> and P2 to implement the DOM 2 Core? See my additional
>> thoughts below.
>
>JRG: I think we have put this one to rest many times, is there new
>information?
>
>>12) Checkpoints 6.1-6.4: Perhaps it's better (though not
>> necessarily simpler) to express these checkpoints as
>> functional requirements. It may turn out that the
>> functional requirements are met by implementing
>> some piece of an API.
>
>JRG: Aren't they functional requirements now?
>
>>=============
>> From the MAC IE review (not yet completed)
>>
>>13) Checkpoint 2.2: "XML and SGML applications". According to Ian
>> Hickson and Tantek Çelik (both there for the evaluation), one
>> cannot reliably determine what's an xml and sgml application by
>> sniffing content. We will need to be more precise about how one
>> would determine that something is an xml or sgml application.
>>
>> I don't have a proposal for this one.
>>
>>14) Checkpoint 3.4: Toggle scripts. Tantek argued that,
>> since most pages include scripts, the following
>> provision should not be P1:
>>
>> "In this configuration, provide an option to alert the
>> user when executable content is available (but has not
>> been executed)."
>>
>> The alert will be so frequent as to be ignored. One
>> suggestion is to pull out this provision and make it a
>> lower priority.
>>
>> Proposal: Make the alert a P3 requirement.
>>
>>15) Checkpoint 6.2: Tantek stated that there are security
>> issues for some types of programmatic access to content.
>> (for instance, programmatic access to HTML's INPUT element,
>> type="file", which might allow the author to upload a file
>> from the user's computer without the user's permission).
>>
>> See my comments below on 6.1, 6.2, and 6.3.
>>
>>16) Checkpoint 6.9: Timely access. The checkpoint reads:
>> "Ensure that programmatic exchanges proceed in a timely
>> manner." It's not clear which exchanges this checkpoint
>> refers to - internal to the user agent? between the UA
>> and ATs?
>>
>> Proposal: This refers to exchanges over the APIs required
>> elsewhere in Guideline 6.
>>
>>17) Checkpoint 7.4: Input configuration indications.
>>
>> Proposal: Clarify that the requirement is to "Follow
>> operating environment *user interface* conventions to
>> indicaxte the input configuration."
>>
>>18) Checkpoints 7.3, 8.1:
>>
>> Proposal: Clarify that the expression "identified as such"
>> means "identified as such in the specification". However,
>> this does not account for W3C Notes such as "Accessibility
>> features of CSS" which may be useful but not normative.
>>
>>19) Checkpoint 9.3: Move content focus.
>>
>> Proposal: In point three, clarify that "each element" means
>> each element in the set defined in point 1. Tantek
>> recommended introducing the term "Focusable element" and
>> using it in point 1.
>>
>>20) Checkpoint 9.4: Restore history. The checkpoint reads:
>>
>> "For user agents that implement a viewport history
>> mechanism, for each state in a viewport's browsing history,
>> maintain information about the point of regard, content
>> focus, and selection."
>>
>> However, even when a user agent implements a history
>> mechanism, it may not keep all pages in its cache.
>>
>> Proposal: Do not require the user agent to restore state
>> variables for pages removed from the history cache.
>>
>>21) Checkpoint 9.7: The checkpoint title is "Move content focus
>> optimally". The word "optimal" is a bit strong.
>>
>> Proposal: Change the title to "Move content focus reverse"
>> since the primary (but not only) difference from 9.3 is the
>> reverse requirement.
>>
>>22) Checkpoints 10.2, 10.3, 10.4, 10.7: The expression "rely on
>> color alone" is ambiguous. In the end, on a color display, all
>> distinguishing marks rely on color (e.g., a solid line is a line
>> of a different color than, say, the background color;
>> three-dimensional effects are due to shading, etc.).
>>
>> Proposal: Given our checkpoint 4.3 (configure text colors), I
>> propose that for the 10.x checkpoints, we modify the language
>> to read "rely on text foreground and background color alone".
>>
>>=============
>>Other observations and points for discussion:
>>
>>Thought 1) I continue to wonder whether 6.1 and 6.2 should be
>>requiring DOM implementation at a P1 level.
>>
>> Pros:
>> - Supposed to promote interoperability by requiring
>> a known API.
>> - An API is supposed to help developers by providing
>> access to incremental changes in content; a simple
>> text dump after any changes may decrease performance
>> by requiring the AT to reparse each time (though in
>> practice, apparently some do this anyway).
>>
>> Cons/Questions:
>> - AT developers may not, in practice, be interested in
>> implementing the DOM, even though in the past they have
>> expressed interest.
>> - Developers can't implement more suitable APIs for a given
>> content type (e.g., SVG) since must implement DOM 2 Core,
>> even though a specific SVG DOM might exist.
>> - It is not guaranteed that the *entire* DOM 2 Core
>> is required to to provide ATs with sufficient access.
>> I don't look forward to requiring some "subset" of DOM 2
>> Level Core, but it would be worthwhile to determine whether
>> nearly all of DOM 2 is required for communication with
>> ATs
>>
>> Some ideas for other changes based on discussions:
>>
>> - Change 6.1, 6.2, and 6.3 to resemble 6.4.
>> For example, a new checkpoint replacing 6.1, 6.2, and 6.3
>> might be:
>>
>> <NEW 6.x>
>> Programmatic access to content (P1)
>> 1. Provide programmatic read access to content.
>> 2. If the user can modify content through the user
>> interface, provide the same functionality
>> programmatically.
>> 3. To satisfy these requirements, implement at least
>> one API that is either
>> * defined by a W3C Recommendation,
>> * a publicly documented API designed to enable
>> interoperability with assistive technologies.
>> 4. If no such API is available, or if available APIs do
>> not enable the user agent to satisfy the requirements,
>> implement at least one publicly documented API that
>> allows programmatic operation of all of the
>> functionalities that are available through the user
>> agent user interface, and follow operating environment
>> conventions for the use of input and output APIs.
>> 5. An API is considered available if the specification of
>> the API is published (e.g., as a W3C Recommendation) in
>> time for integration into a user agent's development
>> cycle.
>>
>> Note: We encourage developers to satisfy this checkpoint
>> by using the DOM Level 2 Core specification for read
>> and write access to XML and HTML content, or a more
>> specific DOM (e.g., for HTML, SVG, or SMIL) when one exists.
>> </NEW 6.x>
>>
>>
>>Thought 2) Change the priorities of some requirements related to
>>default values. A long time ago, Greg Lowney suggested that we
>>should not have priority 1 checkpoints about user agent default
>>styles, but rather priority 1 checkpoints that the user be able
>>to change values, and perhaps priority 2 checkpoints about what
>>the defaults should be. I continue to think that this would be a
>>good change to make, in particular after the evaluations I have
>>done. The following checkpoints relate to default styles:
>>
>> 7.2 Respect input configuration conventions. (P1)
>>
>> 1. Ensure that default input configurations of the user agent
>> do not interfere with operating environment accessibility
>> conventions (e.g., for keyboard accessibility).
>>
>> 10.3 Distinct default highlight styles. (P1)
>>
>> 1. Ensure that all of the default highlight styles for the
>> selection and content focus, as well as for enabled elements,
>> recently visited links, and fee links in rendered content
>> do not rely on color alone, and differ from each other, and
>> not by color alone.
>>
>> 10.7 Highlight current viewport. (P1)
>>
>> 2. For graphical viewports, the default highlight mechanism
>> must not rely on color alone.
>>
>>Proposals:
>>
>> - Checkpoint 11.3 is a P2 ("Allow the user to override any
>> binding that is part of the user agent default input
>> configuration.") I propose making this checkpoint a P1 and
>> making 7.2.1 a P2.
>>
>> - Since checkpoints 10.2 and 10.4 are P1, require the UA to
>> allow the user to configure styles, and cover all the pieces
>> mentioned in 10.3, make 10.3.1 a priority 2 checkpoint. I realize
>> that without 10.3 at a P1 level, the user might not be able
>> to distinguish some highlight styles "out of the box", but I
>> think that should be relatively easy to fix thanks to 10.2 and
>> 10.4
>>
>> - I propose simply lowering the priority of 10.7.2 to P2. I note
>> that we have no requirement that the user be able to configure
>> the style of the viewport highlight mechanism. I don't propose
>> that we add such a requirement.
>>
>>Note: In the above, "10.3.1" refers to checkpoint 10.3,
>>requirement number 1.
>>
>>Note: There are other checkpoints (7.2, about default keyboard
>>configurations. I don't propose that we change their priorities.
>>
>>Thought 3) Clarify the relation between UAAG 1.0 and other
>>specifications. UAAG 1.0 includes requirements for specific
>>features, but also asks for conformance to other specifications
>>(e.g., HTML, CSS, etc.). I would like to add something to the
>>conformance section that clarifies that:
>>
>> a) Developers should follow specifications, especially when
>> consistent with UAAG 1.0 requirements.
>>
>> b) UAAG 1.0 may ask developers to implement optional features,
>> i.e., go beyond what is strictly required for conformance
>> to another specification.
>>
>> c) UAAG 1.0 may ask developers to implement features that
>> are not part of another specification.
>>
>> d) UAAG 1.0 does not make a definitive pronouncement about what
>> to do when a UAAG 1.0 requirement is in direct conflict with
>> the requirement of another specification (something we hope
>> will be rare, and even rarer for W3C specs thanks to the
>> good work of the WAI PF Working Group). I think we should
>> state explicitly that in these cases, UAAG 1.0 would
>> prefer that developers meet the needs of people with
>> disabilities.
>>
>>=============
>>Some comments and questions about evaluations (perhaps should
>>be discussed and added to "How to Evaluate a User Agent" [2])
>>
>> - I think that each requirement of each checkpoint should be
>> rated separately, rather than, say, trying to average 4
>> ratings for the 4 requirements of a single checkpoint.
>>
>> - Should known bugs that are expected to be fixed count
>> against a given rating? I think that bugs should not
>> count against the rating, provided there is a good faith
>> commitment by the developer to fix them. Furthermore, they
>> should be advertised in the claim, not hidden.
>>
>> - How can we calibrate evaluations, i.e., make them more
>> comparable? How do we ensure even rating across evaluations?
>>
>>[2] http://www.w3.org/WAI/UA/2001/10/eval
>>
>>--
>>Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
>>Tel: +1 718 260-9447
>
>Jon Gunderson, Ph.D., ATP
>Coordinator of Assistive Communication and Information Technology
>Division of Rehabilitation - Education Services
>MC-574
>College of Applied Life Studies
>University of Illinois at Urbana/Champaign
>1207 S. Oak Street, Champaign, IL 61820
>
>Voice: (217) 244-5870
>Fax: (217) 333-0248
>
>E-mail: jongund@uiuc.edu
>
>WWW: http://www.staff.uiuc.edu/~jongund
>WWW: http://www.w3.org/wai/ua
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL 61820
Voice: (217) 244-5870
Fax: (217) 333-0248
E-mail: jongund@uiuc.edu
WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua
Received on Wednesday, 13 March 2002 15:27:34 UTC