- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 10 Aug 2000 13:01:19 -0400
- To: w3c-wai-ua@w3.org
"Hansen, Eric" wrote:
>
> Date: 9 August 2000
> To: UAAG List
> From: Eric Hansen
> Re: "Checkpoint applicability", "Native support", etc.
>
> I would like to propose some clarifications, particularly in the areas of
> "Checkpoint applicability" and "Native support".
>
> PR#294: Native support and downloadable modules
> http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#294
>
> PR#309: Applicability needs review: how to tell when checkpoint
> MUST be followed.
> http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#309
>
> I believe that the problems can be corrected as shown below with very little
> change to checkpoints.
> ====
>
> Suggestion 1: Simplify the section on Applicability.
[snipping good rationale and context on applicability]
>
> "The main applicability rule, informally stated, is that a checkpoint is
> _applicable_ to a user agent if the checkpoint requires capabilities that
> the developer of the user agent _intends_ for users _without_ any
> disability.
How does this work for checkpoint 1.1:
1.1 Ensure that every functionality available
through the user interface is also available
through every input API implemented by the
user agent.
This checkpoint is requiring capabilities that may not be intended
for users without any disabilitly. The user interface is meant
for users, and this checkpoint is designed for communication with
other software, which a UA may not do otherwise. The same goes
for the DOM checkpoints; this document requires an implementation
of the DOM, whether or not the UA already chose to implement the
DOM for all users.
[snipped more good stuff]
> "One implication of the main rule is that a checkpoint is not applicable if
> it refers solely to capabilities that, in a given user agent, are
> exclusively for people _with_ disabilities.
Doesn't this contradict the checkpoints such as 1.1 that require
communication for the purpose of interaction with ATs?
> "An obvious but extremely important implication of this applicability rule
> is that a checkpoint is "not applicable" if is refers exclusively to
> capabilities that are _not offered by the user agent at all_.
Yes.
> ====
>
> Suggestion 2: Remove or delete the summary examples from "Checkpoint
> applicability".
>
> I think that the summary examples as well as the sentence following the
> examples should be deleted or removed. Possibly some version might be
> warranted for the Techniques.
Yes.
> Following are justifications for this
> suggestion. Each point is followed by my comments.
[snipped]
I would like to remove the explicit list from the guidelines and
move to techniques in some form if your expression of applicability
can be improved after discussion.
> ====
>
> Suggestion 3: Mention applicability, at least "softly", in the Abstract.
>
> I think that a good first step to clarifying the role of "applicability" in
> the guidelines is by invoking the concept of "applicability" in the Abstract
> (and any other relevant locations).
Yes, this makes sense.
[snip]
> Comment 3:
>
> The revised version does not say "assistive technologies"; it just says
> "technologies". The term "assistive technologies" may cause readers to
> incorrectly infer that the UAAG is about hardware, which it is not.
I don't agree here. I think that we can use the term (which we use
elsewhere in the document, so why avoid it here?), which links to
a definition.
> Furthermore, "assistive technologies" may be seen as partially overlapping
> with "voice browsers" and "text browsers", which could add confusion.
> ====
>
> Suggestion 5: Seriously consider giving explicit permission to create a
> single user agent out of more than one user agent.
>
> Actually, I see no reason why developer, if she or he desires, should not
> treat two or more cooperating user agents (i.e., a general-purpose graphical
> user agent plus a multimedia player plus some special-purpose
> disability-access user agent, etc.) as a single user agent. First of all,
> this is the way it happens in real life; for example, MS Internet Explorers
> uses lots of special purpose plug-ins. Second, this would encourage
> cooperation between developers on disability access issues. It might be
> possible, for example, for two user agents, one or more of which is
> non-compliant when analyzed singly, but together constitute a "super" user
> agent that is compliant. Such a possibility would encourage cooperation
> between developers of user agents. Third, this would encourage involvement
> by lots of developers of special-purpose user agents (assistive
> technologies). Without this change, they may feel left out because they do
> not address all disabilities or because few checkpoints are applicable to
> them. But if they can cooperate with other user agents to form a combined
> "super" user agent, then they can join the party. It would be a win-win
> situation. I suppose that one could not say anything about this issue in
> this document and leave it up to others to decide if they want to allow it.
> Nevertheless, my feeling is that it makes a lot of sense and if others
> agree, then we should explicitly allow it in the document.
I think I agree with this. See my other comments on conformance [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0230.html
> ====
>
> Suggestion 7: Remove the reference to "assistive technologies" in checkpoint
> 1.5.
>
> I think that "assistive technologies" (and its variations) need not and must
> not appear in checkpoint 1.5 (i.e., the normative part) or any other
> checkpoint. One reason is that people may incorrectly assume that because
> the checkpoint refers to requirements that are exclusively for people with
> disabilities, such as those relating to "assistive technologies", that the
> checkpoint is somehow not applicable.
>
> Fortunately, it appears checkpoint 1.5 is the only checkpoint that uses that
> term and it is in no way essential. In my opinion, this checkpoint also has
> other problems, such as misuse of the term of the term "text equivalent".
> Let us consider basic fix.
>
> Old (UAAG 28 July 2000):
>
> "1.5 Ensure every non-text message (e.g., prompt, alert, notification, etc.)
> that is part of the user agent's user interface also has a text equivalent
> in the user interface. This text equivalent must be available to assistive
> technologies through an API. [Priority 1]"
>
> Partial Fix 1:
>
> "1.5 Ensure every non-text message (e.g., prompt, alert, notification, etc.)
> that is part of the user agent's user interface also has a text equivalent
> available in the user interface. [Priority 1]"
>
> Comment 1:
>
> There are already checkpoints that ensure that the text equivalents will be
> available through the interface (e.g., checkpoints 2.1, 2.2, and 2.4) and
> checkpoint 1.1 ensures that what is available through the user interface is
> also available through API. So that second sentence -- the one that refers
> to assistive technology -- is completely unnecessary.
Ok.
> Comment 2:
>
> As noted above, other fixes are also needed. One problem is that it misuses
> the term "text equivalent". We can correct part of the problem as follows:
>
> Partial Fix 2:
>
> "1.5 Ensure every non-text message (e.g., prompt, alert, notification, etc.)
> that is part of the user agent's user interface also has a text equivalent.
> [Priority 1]"
>
> I removed the last part of the sentence because a text equivalent is
> "pre-rendering content" so it usually doesn't make sense to talk about "text
> equivalent available in the user interface".
yes.
> I wonder if what was really meant was to emphasize that visual messages
> should have an auditory equivalent and auditory messages should have a
> visual equivalent. I suppose that there may have been a desire to emphasize
> this in the UAAG document since some of these messages seem to be generated
> by the user agent itself or the operating system than by the Web content
> itself. Unless someone can explain the intention of the checkpoint, I think
> that this checkpoint is not necessary at all since it is adequately covered
> by other checkpoints.
>
> Therefore I suggest deleting it. Even if it is not deleted, I strongly urge
> removal of reference to assistive technologies.
>
> ====
>
> Suggestion 7: Keep mention of "compatibility and quick communication with
> assistive technology" out of any checkpoint.
>
> This is not actually a problem at this time since, I don't think that they
> are mentioned in checkpoints. This is more for future reference.
> "[C]ompatibility and quick communication with assistive technology" are part
> of the "near-ideal conditions" (that I think are more properly called
> "standard conditions") and therefore should not be found in any checkpoint.
> These are things that are and should remain outside the scope of the
> checkpoints themselves.
Ok.
Thanks Eric!
_ Ian
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Thursday, 10 August 2000 13:01:26 UTC