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 18:21:27 UTC