RE: Normative issue summary for 2.1

Hi Tim - 

There is an element of closing issues because they can't be addressed
right away. Basically we need to close all these issues before the next
public draft, and right now is really the only time to do it (we'll be
responsible for going through the same exercise for a whole other
guideline next week). So, in the time I had available to work on
proposals, I tried to make suggestions that I thought could close these
issues. I tried to provide some rationale for each one, but I was quite
brief at times.

That said, if there is concern about any of these issues, we should not
just close them for the sake of closing them. They'll just come up later
and be problems again. Bigger problems, because after Last Call the
process to handle issues becomes more formal, which is to say slower.
This is why I sent the proposals to the Team C list first, not to the
main list and not as a survey yet. If you think particular issues will
be problems in this way, please flag them and ask that we discuss
further. The ones that don't get flagged we can proceed to close, and
then focus on the rest. 

To be most useful, objections to closing issues should be accompanied by
alternate proposals for each issue. Somebody will have to make a
proposal anyway, and it will be more efficient for us to discuss in the
context of a proposal than to discuss, go off to make a proposal, then
come back and discuss again. If you feel the issue should not be closed
but are unable to suggest a better approach, it is ok to say so, but we
may not be in a good position to handle such issues. 

We need to have a goal that no issue gets "postponed". Last Call is, by
definition, a draft where we think we've handled all the issues we were
aware of. Only new issues that we didn't think of, ideally, will come up
after Last Call. Repeat issues will most likely get handled by simply
copying the rationale for closing the issue previously. The rationale
should therefore be good enough that we can expect people to accept it -
even if they don't like it - and if you believe that is not the case
with some of the proposals, definitely flag those so we can focus on
them.

Michael

-----Original Message-----
From: public-wcag-teamc-request@w3.org
[mailto:public-wcag-teamc-request@w3.org] On Behalf Of Tim Boland
Sent: Thursday, January 05, 2006 11:32 AM
To: public-wcag-teamc@w3.org
Subject: 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 17:19:52 UTC