Re: Normative issue summary for 2.1

Do we have sufficient rationale/explanation for closing the issues that are 
recommended
to be closed? I'm a tiny bit concerned that issues are being closed just 
for the sake of keeping to a time
schedule?   If issues are being closed because they cannot be addressed in
this version of WCAG, can they be reopened for a future version? Can issues
be "postponed" to a future version when more information/experience on them is
available?

Just a general feeling of mine..

Michael, thanks for the great work in these recommendations!

Happy new year to everyone,
Tim Boland NIST

At 01:21 PM 1/4/2006 -0500, you wrote:

>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 Thursday, 5 January 2006 16:33:07 UTC