- From: Loretta Guarino Reid <lguarino@adobe.com>
- Date: Mon, 23 Oct 2006 15:20:18 -0700
- To: <public-wcag-teamb@w3.org>, <public-wcag-teamc@w3.org>, <public-wcag-teama@w3.org>
- Message-ID: <EDC8DDD212FEB34C884CBB0EE8EC2D91028EA654@namailgen.corp.adobe.com>
"AT-Push" Sort Item
Summary of Issues:
1. The roles and other properties exposed by ARIA enable user
agents to provide the textual information required by some SC. Would
that be an acceptable technique for satisfying SC that require textual
information? How does the current lack of User Agent/AT support for ARIA
affect the answer?
2. Some proposed techniques are not well supported by user agents
and AT and have extension User Agent notes. Should such techniques be
sufficient? Should we be trying to influence UA and AT vendors to
support them by including the techniques in WCAG?
*****************************************************************
Comment LC-630
Sort Terms: AT-push
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com> Affiliation: Invited
expert at W3C, UB access
Comment Type: substantive
Location: minimize-error <http://www.w3.org/TR/WCAG20/complete.html>
(Level 2 Success Criteria for Guideline 2.5)
Comment:
Comment (including rationale for any proposed change):
2.5.2 If an input error is detected and suggestions for correction are
known and can be provided without jeopardizing the security or purpose
of the content, the suggestions are provided to the user.
With things like role attribute you can assign a functional role to an
element, and other important information such as allowable range. That
means that the assistive technology can themselves perform validation.
Makes it all a user agent thing...
Proposed Change:
2.5.2 If an input error is detected and suggestions for correction are
known and can be provided without jeopardizing the security or purpose
of the content, the suggestions are provided to the user or can be
programmatically determined
Status: open
Working Group Notes: [TEAMC] [HOLD]
Relates to LC-629 LC-631 LC-632
Proposal to the team C list at
http://lists.w3.org/Archives/Public/public-wcag-teamc/2006Jun/0011.html.
Discussed at June 5, 2006 Team C meeting.
--
Discussed on the 22 June 2006 teleconference
Group agrees in principle with the response to not update the SC text.
Update response text "suggestions for error correct" with "suggestions
for error correction", Leave open and assign to Loretta to work out
final language for HTM doc.
http://www.w3.org/WAI/GL/2006/06/22-wai-wcag-minutes.html
{partial accept}
@@ Loretta: clarify in the understanding document that there could be
technology specific SC that do this
RESPOND WITH: The current success criterion does not prevent use of
Dynamic Web Content Accessibility, XForms or other technologies to add
information that will allow assistive technologies to provide
suggestions for error correction. We do not feel we need to specifically
add "programmatically determined" to the success criterion in order to
support this additional data. If role and validation information is
programmatically provided in the markup and testing demonstrates that
suggestions for error correction are provided to the user via the user
agent or assistive technology, this success criterion has been
satisfied. When assistive technology is available which supports this
level of validation and correction, the working group will add an
advisory technique for this success criterion. When this is generally
supported by all AT then it could be added as a sufficient technique.
---
@@See action from 22 June 2006 meeting
<http://www.w3.org/WAI/GL/2006/06/22-wai-wcag-minutes.html#item08>
<http://www.w3.org/WAI/GL/2006/06/22-wai-wcag-minutes.html> ;
Resolution Working Notes - Unapproved:
{partial accept}
@@ Add the following techniques to Situation A and Situation B of SC
2.5.2:
Identifying the field as mandatory USING a technology-specific technique
below (for a technology in your baseline)
Identifying the required format or values of a field USING a
technology-specific technique below (for a technology in your baseline)
RESPOND WITH: The current success criterion does not prevent use of
Dynamic Web Content Accessibility, XForms or other technologies to
provide information that will allow user agents and assistive
technologies to provide suggestions for error correction. We do not feel
we need to specifically add "programmatically determined" to the success
criterion, but we have added placeholders for such technology-specific
techniques. If role and validation information is programmatically
provided in the markup for a technology and testing demonstrates that
suggestions for error correction are provided to the user via the user
agent or assistive technology, this success criterion has been
satisfied. The technology-specific techniques should be provided for
such technologies.
Comment LC-631
Sort Terms: AT-push
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com> Affiliation: Invited
expert at W3C, UB access
Comment Type: substantive
Location: minimize-error <http://www.w3.org/TR/WCAG20/complete.html>
(Level 2 Success Criteria for Guideline 2.5)
Comment:
Comment (including rationale for any proposed change):
With things like role attribute you can assign a functional role to an
element, and other important information such as allowable range. That
means that the assistive technology can themselves perform validation.
We should also work on identifying critical tasks.
Hence one of the list should be (for future proofing) the role of all
information and it's critical nature can be programmatically determined
Proposed Change:
1. Actions are reversible.
2. Actions are checked for input errors before going on to the next step
in the process.
3. The user is able to review and confirm or correct information before
submitting it.
4. The role of each control and its critical nature can be
programmatically determined.
Status: open
Working Group Notes: [TEAMC] [HOLD]
Relates to LC-629 LC-630 LC-632
Proposal to the team C list at
http://lists.w3.org/Archives/Public/public-wcag-teamc/2006Jun/0011.html.
Discussed at June 5, 2006 Team C meeting.
--
Discussed on the 22 June 2006 teleconference
Resolution: Put issue 631 on hold in the "AT push" category. Assign
action to Loretta to address this issue.
http://www.w3.org/WAI/GL/2006/06/22-wai-wcag-minutes.html
6/22 proposal:
@@@{partial accept}
RESPOND WITH: Since there is currently no mechanism to specify the
critital nature of a control using current technologies we can not
require that level of information in a success criterion. For example,
in HTML there is no attribute on an input element to specify that it is
required. The current success criterion does not prevent use of the
Dynamic Web Accessibility or future technologies to add information that
will allow assistive technologies to provide suggestions for error
correction. When assistive technology is available which supports
validation and correction via specification of additional meta-data, the
working group will add an advisory technique for this success criterion.
Resolution Working Notes - Unapproved:
{not accept}
RESPOND WITH:
This success criterion is addressing the problem of users making
irreversible mistakes in the otherwise valid values provided or actions
taken. Indicating that a control is critical is not sufficient to
satisfy this success criterion. The user must still be given the
opportunity to avoid unrecoverable errors.
Comment LC-632
Sort Terms: AT-push
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com> Affiliation: Invited
expert at W3C, UB access
Comment Type: substantive
Location: minimize-error-context-help
<http://www.w3.org/TR/WCAG20/complete.html> (Level 3 Success Criteria
for Guideline 2.5)
Comment:
Comment (including rationale for any proposed change):
With things like role attribute and concept mapping with RDF you can
assign a functional role to an element, That means that the assistive
technology can themselves provide the correct help that is tailored to
the user. The user experience is better because the help is tailored to
their scenario
Proposed Change:
2.5.4 Context-sensitive help is available for text input or the role of
each control can be programmatically determined
Status: open
Working Group Notes: [TEAMC] [HOLD]
Proposal to the team C list at
http://lists.w3.org/Archives/Public/public-wcag-teamc/2006Jun/0011.html.
Discussed at June 5, 2006 Team C meeting.
Relates to LC-629 LC-630 LC-632
Proposal to the team C list at
http://lists.w3.org/Archives/Public/public-wcag-teamc/2006Jun/0011.html.
Discussed at June 5, 2006 Team C meeting.
--
Discussed on the 22 June 2006 teleconference
Resolution: Put issue 631 on hold in the "AT push" category. Assign
action to Loretta to address this issue.
http://www.w3.org/WAI/GL/2006/06/22-wai-wcag-minutes.html
Resolution Working Notes - Unapproved:
@@@{partial accept}
@@ Add to techniques for Situation B:
Identifying the required format or values of a field USING a
technology-specific technique below (for a technology in your baseline)
RESPOND WITH: The current success criterion does not prevent use of
Dynamic Web Content Accessibility or other technologies to add
information that will allow user agents or assistive technologies to
provide context-sensitive help. We do not feel we need to specifically
add "programmatically determined" to the success criterion in order to
support this additional data, but we have added a placeholder for such
technology-specific techniques. If additional information is
programmatically provided in the markup and testing demonstrates that
context sensitive help is provided to the user via the user agent or
assistive technology, this success criterion has been satisfied. The
technology-specific techniques should be provided for such technologies.
Comment LC-1078
Sort Terms: at-push
Document: Understanding WCAG 2.0
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: substantive
Location: content-structure-separation-programmatic
<http://www.w3.org/TR/UNDERSTANDING-WCAG20/> (HTML Tech)
Comment:
SCOPE: One of the HTML techniques is to use the scope attribute to
associate header cells and data cells in tables. Research has shown that
SCOPE is not supported by any known assistive technology and therefore
should not be advocated.
Proposed Change:
Remove the SCOPE HTML technique, OR indicate that it is not supported
yet, and TH & TD are preferable
Status: open
Working Group Notes: [TEAMC] [HOLD]
The scope element is supported by HPR.
I did quite a bit of testing and worked with Jim Thatcher and spoke with
Alan Cantor also. Jim has provided this test page which I have posted
at:
http://www.eramp.com/david/tablesample2.htm
Technique H63 User Agent and Assistive Technology Support Notes
says:
"The scope attribute is not supported by current screen readers when
there is more than one row of headers and the scope attribute is used on
the first row."
I think it would be more accurate to say:
"The scope attribute is not supported by most current screen readers and
it is advisable at the current time to use the TH element instead. The
visual presentation of TH element can be adjusted using stylesheets (see
###)"
Resolution Working Notes - Unapproved:
[partial accept]
@@move H63 to an advisory technique for 1.3.1 instead of sufficient
@@change the "User Agent and Assistive Technology Support Notes"
for H63 to:
"The scope attribute is not supported by most current screen readers and
it is advisable at the current time to use the TH element instead. The
visual presentation of TH element can be adjusted using stylesheets (see
###)"
@@Add a note to :H51: Using table markup to present tabular information
" and H43: "Using id and headers attributes to associate data cells with
header cells in data tables"
The note would say: "Note: It is advisable at the current time to use
the TH element to mark up headings, instead of the scope attribute. The
Scope element is not supported by most current screen readers. Visual
presentation of TH element can be adjusted using stylesheets (see ###)"
respond with:
We have moved the technique from sufficient to advisory and we have put
a note on it that says:
"The scope attribute is not supported by most current screen readers and
it is advisable at the current time to use the TH element instead. The
visual presentation of TH element can be adjusted using stylesheets (see
###)"
We have added a similar note to the table techniques (H51 and H43)
recommending the TH element over the Scope element and suggesting the
use of Stylesheets to adjust the look of the TH element. The WCAG WG is
reluctant to remove the Scope technique completely because it should be
useful and its inclusion in the document may influence AT to support it.
IBM HPR currently does supports the Scope element.
Closed Issues
Comment LC-557
Sort Terms: AT-Push link-text title-attribute
Document: Techniques Document
Submitter: steve faulkner <steven.faulkner@nils.org.au>
Comment Type: substantive
Location: <http://www.w3.org/TR/WCAG20-TECHS/> (Applicability)
Comment:
Part of Item: Applicability
Comment Type: TE
Comment (including rationale for proposed change):
2.4.4 Each link is programmatically associated with text from which its
purpose can be determined. (Level 2)
"The intent of this success criterion is to help users understand the
purpose of each link in the content"
The intent of the criterion is not met by the use of technique H33.
Critisisms of Technique H33
"User agents will display a tool tip when the mouse hovers above an
anchor element containing a title attribute."
1. Current User agents do not provide access to title attribute content
via the keyboard [1]
a. Will result in content not being accessible by non-mouse users who do
not use screen reading software.
b. Contradicts the intent of Guideline 2.1 Make all functionality
operable via a keyboard interface.
c. Contradicts the intent of Guideline 4.2 Ensure that content is
accessible or provide an accessible alternative, because the technique
does not include advice that an accessible alternative version of the
content within the title attribute be provided.
2. The "tool tip" in some commonly used user agents disapears after a
short period of time (approximately 5 seconds) [1]
a. Will result in difficulty accessing title attribute content for those
users who can use a mouse, but have fine motor skill impairment.
b. May result in reading difficulties of title attribute content for
users with cognitive/learning impairment.
c. Contradicts the intent of Guideline 2.2 Allow users to control time
limits on their reading or interaction.
3. Presentation of title attribute content cannot be resized or colours
changed via the user agent or by the content author.
a. The foreground and background colours of the "tool tip" cannot be
modified by the user via the user agent.
b. The size of the text within a "tool tip" cannot be modifed by a user
via the user agent.
c. Contradicts the intent of Guideline 1.3 Ensure that information and
structure can be separated from presentation
4. The placement and location of the "tool tip" cannot be modified by
users.
a. This results in some screen magnifier users being unable to access
meaningful portions of the title attribute content, because the "tool
tip" cannot be fully displyed within the view port [2].
Assistive technology issues
Three pieces of assistive technology are cited in the "User Agent and
Assistive Technology Support Notes" [4]. Two of those cited do not
provide a practical or functionally equivalent method for users to
access the information within the title attribute of links.
JAWS 7.0
"JAWS 7.0 will speak either the link text or the title attribute for a
link depending upon a JAWS setting. This setting can be changed
temporarily or permanently within JAWS."
Discussion
JAWS does not provide a practical or functionally equivalent method for
users to hear the content of a link's title attribute
If a user has JAWS set to read "Title text" for links they cannot access
the "screen text" without changing the JAWS verbosity settings (This
process involves a minimum of 7 keystrokes / keystroke combinations and
in 5 out of 7 tests caused JAWS to start reading again from the top of
the page, thus losing focus on the link that had a potential "title
text".).
So in Example 2 (
Table 1) of technique H33 a JAWS user with verbosity set to "use title"
for links would hear
"link opens in new window"
, but would not hear
"Subscribe to email notifications about breaking news"
, nor would they be given any indication that this additional
information was available and could not access the information without
going through these steps:
In order for a user to change the verbosity setting for links a user
must:
"press INSERT V to open the Adjust JAWS Verbosity dialog box. Select an
option with the arrow keys and then press SPACEBAR or use the Execute
button to cycle through the available settings. Press ENTER to accept
your changes and close the dialog box. " [3]
Conversely if the user had the default "screen text" settings they would
not hear the information \"link opens in new window\" nor would they be
given any indication that this additional information was available.
Table 1 H33: Supplementing link text with the title attribute - Example
2
<a href=\"http://www.newsorg.com.com/subscribe.html\" target=\"_blank\"
title=\"link opens in new window\"> Subscribe to email notifications
about breaking news</a>
Homepage Reader 3.04
"Home Page Reader 3.04 will speak the title attribute of any element
with focus when the control-shift-F1 keys are pressed simultaneously."
* This is not a documented feature of HPR 3.04. The documentation in
reference to this states that the URL of the page will be read out (no
mention of the title attribute).
* The title attribute content is read out, but after the URL of the
current page is read.
* The user has no way to know that there is supplementary information
available unless he/she activates the key combination. It is totally
impractical to expect users to query each link to find supplementary
information.
References
1. Display of the TITLE attribute in some common browsers -
http://www.sf.id.au/WE05/#slide7 <http://www.sf.id.au/WE05/>
2. Screen Magnifier users - http://www.sf.id.au/WE05/#slide12
<http://www.sf.id.au/WE05/>
3. JAWS 6 documentation - JAWS 6.20 documentation [EXE file, 1.57 MB]
4. Technique H33 - Supplementing link text with the title attribute
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H33
<http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html>
Proposed Change:
Remove technique H33
Status: Resolved (resolved_partial).
Working Group Notes: [TEAMB] []
Related comments: 497 573 576 473
Discussed at Team B meeting on 6-27-2006. Decide to incorporate comments
from Team B Survey results of June 22
(http://www.w3.org/2002/09/wbs/35422/teamb062206/results) into the
database.
Because of Ben Caldwell's comments to Keep Open, decided to move to HOLD
and add to user_agent keyword.
Discussed at WCAG full meeting on 6-29-2006.
OUTCOME from July 29 Full WCAG Discussion: Make it AT Push (new key
word). Put on hold.
Discussed in the 19 October 2006 telecon:
resolution: accept LC-557 and LC-1108 as amended
http://www.w3.org/WAI/GL/2006/10/19-wai-wcag-minutes.html
Resolution - Pending Response:
{reject? partial accept?}
@@See changes in wiki:
http://trace.wisc.edu/wcag_wiki/index.php?title=Supplementing_link_text_
with_the_title_attribute
@@ Response to Commenter:
We have added the information you provided to the (long) list of user
agent notes for this technique. The working group would like to see
better user agent support for the title attribute, but feels that this
should reamain a sufficient technique while efforts to improve user
agent and assistive technology support are made. It has been made an
advisory technique for SC 2.4.8, since the link text itself must be
sufficiently descriptive without depending upon the title attribute
content.
Because title attributes should only be used for supplementary
information, we have added a sentence to the Intent section "If the
supplementary information provided through the title attribute is
something the user should know before following the link, such as a
warning, then it should be provided in the link text rather than in the
title attribute." We also included a Failure Example where the title
attribute contains non-supplementary information about the link.
Related Issues:
1108 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1108>
Comment LC-1108
Sort Terms: title-attribute AT-Push
Document: Understanding WCAG 2.0
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: substantive
Location: navigation-mechanisms-refs
<http://www.w3.org/TR/UNDERSTANDING-WCAG20/> (Techniques)
Comment:
TITLE attribute: Recent research has discovered that screen readers
differ in how they read the TITLE attribute and some assistive
technologies, such as magnifiers usually can't access the information at
all.
Proposed Change:
Remove the TITLE attribute technique or specify that it is not supported
on a variety of assistive technology
Status: Resolved (resolved_yes).
Working Group Notes: [TEAMB]
Discussed in the 19 October 2006 telecon:
resolution: accept LC-557 and LC-1108 as amended
http://www.w3.org/WAI/GL/2006/10/19-wai-wcag-minutes.html
Resolution - Pending Response:
{Accept}
@@SEE ACTIONS FOR LC-577
@@Response to commenter
We have added more user agent and assistive technology limitations in
their support for the title attribute. The working group would like to
see better user agent support for the title attribute, but feels that
this should reamain a sufficient technique while efforts to improve user
agent and assistive technology support are made. It has been made an
advisory technique for SC 2.4.8, where the link text itself must be
sufficiently descriptive without depending upon the title attribute
content.
Related Issues:
557 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=557>
Received on Monday, 23 October 2006 22:20:38 UTC