Re: Normative issue summary for 2.1

My responses are below, but the short of it is that I agree will all your recommendations.

Normative issue summary for 2.1


561. Divvying up responsibility for keyboard access
MC Proposal: CLOSE.  
KHS: Agree

941. Format notes in Level 1 SC as a list
MC Proposal: LEAVE OPEN and address when formatting of guidelines is
cleaned up.
KHS: Agree

986. prefer 1.0 approach: "device-independence" is more strict
MC Proposal: CLOSE with no action.
KHS: Agree

1015. If the browser doesn't support tabbing, what is the author to do?
MC Proposal: CLOSE.
KHS: Agree

1378. Difference between 'operable' and 'is designed to be operated'
MC Proposal: CLOSE with the above rationale and reword 2.1.2 as suggested
by Becky: "All functionality of the content is operable through a
keyboard interface."
KHS: Agree

1621. 2.1 L3 SC1 fold into 2.1 L1 SC1
MC Proposal: CLOSE with no action.
KHS: Agree

1700. Usability issues in keyboard access
MC Proposal: Proposal: CLOSE with no action.
KHS: Agree

1738. GL 2.1 Guideline should promote device independence
MC Proposal: MARK AS DUPLICATE of issue 986 (see above) and handle in that context. 

CLOSE with no action.
KHS: Agree

1740. GL 2.1 L3 SC 1 should be Level 2
MC Proposal: Proposal: CLOSE with no action.
KHS: Agree

1804. SC 2.2.1 hard to understand
MC Proposal: Proposal: KEEP OPEN and ask reviewer to suggest wording.
KHS: Agree

1829. Problems with access keys
MC Proposal: Proposal: RECATEGORIZE issue as non-normative. Suggest when / if we ever
get to it in its new category, advisory information be added to the
appropriate technique.
KHS: Agree

1836. GL 2.1: use "textual interface" rather than "keyboard interface"
MC Proposal: Proposal: KEEP OPEN and ask reviewer for substantiation. If we do not
receive it in an appropriate amount of time, CLOSE issue with no action,
otherwise consider the merits at that time.
KHS: Agree

1837. SC 2.1.1: Issues with time-dependency aspects and exception
MC Proposal: Proposal: CLOSE this issue with no action.
KHS: Agree

1838. SC 2.1.1, Benefits in Understanding WCAG
MC Proposal: Proposal: CLOSE this issue, proposing a placeholder optional technique
for the first suggestion, and adding a benefit for the second
suggestion.
KHS: Agree
 
1873. MouseKeys note
MC Proposal: Proposal: CLOSE issue, making changes to the note.
KHS: Agree

1874. Add "non time-dependent manner" to 2.1.2
MC Proposal: Proposal: CLOSE this issue, adding "...in a non time-dependent
manner..." to 2.1.2.
KHS: Agree







-----Original Message-----
>From: Michael Cooper <michaelc@watchfire.com>
>Sent: Jan 4, 2006 1:21 PM
>To: public-wcag-teamc@w3.org
>Subject: Normative issue summary for 2.1
>
>
>I took on myself the task of doing an issue summary of normative issues
>for guideline 2.1 <http://tinyurl.com/ae39v>. Please comment on these on
>the Team C list. Sorry this doesn't give much notice before the group
>call tomorrow, but that's the timing I could manage.
>
>561. Divvying up responsibility for keyboard access
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=561>
>
>This issue asks to what extent keyboard accessibility is an authoring
>responsibility versus a user agent responsibility. The final comment
>mentions that the baseline impacts this.
>
>Proposal: CLOSE
>
>Regardless of where the responsibility lies, or whether applicable
>technologies execute their responsibilities properly, the functional
>requirement in WCAG 2.0 is that keyboard access must exist. Techniques
>may provide guidance about ensuring this requirement is met, but the
>responsibility does not affect the normative requirement.
>
>941. Format notes in Level 1 SC as a list
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=941>
>
>Formatting request.
>
>Proposal: LEAVE OPEN and address when formatting of guidelines is
>cleaned up.
>
>986. prefer 1.0 approach: "device-independence" is more strict
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=986>
>
>This questions the move from "device independence" to "keyboard access".
>There are reasons to be more concrete about keyboard access, but there
>is a proposal to include the more generic device independence at Level
>2.
>
>Proposal: CLOSE with no action. I think this might draw concern but do
>not have a proposal to make that I think would draw less concern.
>
>1015. If the browser doesn't support tabbing, what is the author to do?
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1015>
>
>Asks how to meet this guideline if the user agent does not support
>keyboard navigation between links and form controls.
>
>I think this is similar to issue 561 above, it's a functional
>requirement that must be met regardless of user agent or technology
>issues.
>
>Proposal: CLOSE with the above rationale.
>
>1378. Difference between 'operable' and 'is designed to be operated'
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1378>
>
>2.1.1 uses "operable" while 2.1.2 uses "designed to be operated". The
>question is if there is a difference, and if so, what. 
>
>I believe there is indeed a difference between those terms. There is
>debate about whether there is a call for the second term, but I think
>only the first term should be used. Content that was designed to be
>operated with the keyboard, but not actually operable, would not provide
>the accessibility we're looking for.
>
>Proposal: CLOSE with the above rationale and reword 2.1.2 as suggested
>by Becky: "All functionality of the content is operable through a
>keyboard interface."
>
>1621. 2.1 L3 SC1 fold into 2.1 L1 SC1
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1621>
>
>Greg Lowney raised concerns about "described in a sentence" for 2.1.1.
>He proposed modifying the SC to remove the conditions, which is
>essentially promoting 2.1.2 to replace 2.1.1. 
>
>The concerns were accepted and the success criteria modified, but not
>all conditions were removed from it. Therefore 2.1.1 and 2.1.2 are still
>distinct and this issue is, in a sense, overcome by events.
>
>Proposal: CLOSE with no action.
>
>1700. Usability issues in keyboard access
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1700>
>
>Raises point that keyboard access isn't helpful if tab order makes it
>effectively unusable.
>
>I believe this is covered by 2.4.7 <http://tinyurl.com/9sfb4> and 3.1.6
><http://tinyurl.com/9l5kc>.
>
>Proposal: CLOSE with no action.
>
>1738. GL 2.1 Guideline should promote device independence
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1738>
>
>This asks about changing device independence to keyboard access.
>
>Proposal: MARK AS DUPLICATE of issue 986 (see above) and handle in that
>context.
>
>1740. GL 2.1 L3 SC 1 should be Level 2
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1740>
>
>Suggests moving 2.1.2 (keyboard access, no exceptions) from Level 3 to
>Level 2.
>
>I believe in discussions people have been able to think of situations
>where keyboard access cannot be provided on Level 2 sites, because of
>timing issues (exception-less timing issues are also Level 3). Therefore
>this is a Level 3 issue that not all sites will be able to meet, though
>hopefully most will.
>
>Proposal: CLOSE with no action.
>
>1804. SC 2.2.1 hard to understand
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1804>
>
>Expresses concern that people will not know what the phrase "where the
>task
>requires analog, time-dependent input" means.
>
>I agree with the issue but do not have a proposal to make myself.
>
>Proposal: KEEP OPEN and ask reviewer to suggest wording.
>
>1829. Problems with access keys
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1829>
>
>Raises the browser conflicts issue with access keys.
>
>This is a well known and important issue, but it is squarely a user
>agent issue. Also, currently so "sufficient" techniques call for access
>keys.
>
>Proposal: RECATEGORIZE issue as non-normative. Suggest when / if we ever
>get to it in its new category, advisory information be added to the
>appropriate technique.
>
>1836. GL 2.1: use "textual interface" rather than "keyboard interface"
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1836>
>
>Proposes using a term "textual interface" instead of "keyboard
>interface" for consistency with other W3C groups and be more device
>independent.
>
>I can see merit to the proposal, though I'd be concerned that "textual
>interface" will be harder for people to understand and to define
>properly. Nevertheless if other W3C groups are using the term, we
>should. However, the comment does not provide info about which groups
>use the term or how. A quick search of the W3C site
><http://tinyurl.com/9tx6n> does not yield promising results.
>
>Proposal: KEEP OPEN and ask reviewer for substantiation. If we do not
>receive it in an appropriate amount of time, CLOSE issue with no action,
>otherwise consider the merits at that time. 
>
>1837. SC 2.1.1: Issues with time-dependency aspects and exception
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1837>
>
>This says the inclusion of time-independence in the requirement is
>redundant with success criterion 1.2.2 yet as written it removes the
>requirement completely for any time-dependent activity.
>
>To be honest, I don't understand this comment at all. I don't see the
>relationship with 1.2.2, nor understand the benefit of removing the time
>dependency exception. Considering that benefit has been carefully
>considered by the working group, I would be cautious about proposing to
>remove it. I therefore have to propose no action, and someone can make
>an alternate proposal if they want.
>
>Proposal: CLOSE this issue with no action.
>
>1838. SC 2.1.1, Benefits in Understanding WCAG
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1838>
>
>Makes two points:
>
>1. Having a cut/paste model is a technique, not a benefit.
>2. Also benefits users whose motor control is not sufficient to use a
>pointer device effectively.
>
>These make sense, though it took quite a bit of thinking to understand
>the first one.
>
>Proposal: CLOSE this issue, proposing a placeholder optional technique
>for the first suggestion, and adding a benefit for the second
>suggestion.
>
>1873. MouseKeys note
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1873>
>
>Says the note about MouseKeys, which is a specific technology, should be
>moved to a non-normative document.
>
>I'm inclined to agree with this, but I suspect a note to this effect
>does need to be in the normative document. I think we should instead
>generalize the language. Rewording for the note could be "It is not
>possible to conform to this success criterion by expecting users to use
>keyboard-operated mouse simulation software."
>
>Proposal: CLOSE issue, making above change to the note.
>
>1874. Add "non time-dependent manner" to 2.1.2
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1874>
>
>Asks if the Level 3 criterion should also include a statement about
>operable in a non time-dependent manner, as the Level 1 criterion does,
>in order that the Level 3 one not be weaker.
>
>I'm guessing this would meet the desire to have the Level 3 SC as
>similar as possible to the Level 1, without the exception.
>
>Proposal: CLOSE this issue, adding "...in a non time-dependent
>manner..." to 2.1.2.
>
>--- Signature ---
>
>Michael Cooper
>Accessibility Product Manager, Watchfire
>1 Hines Rd Suite 200, Kanata, ON  K2K 3C7  Canada
>Tel: +1 (613) 599-3888 x4019
>Fax: +1 (613) 599-4661
>Email: michaelc@watchfire.com
>Web: http://www.watchfire.com/ 
>
>

Received on Wednesday, 4 January 2006 19:53:38 UTC