Evaluation and Repair Tools Techniques Issues List
Last revised: $Date: 2004/01/13 23:01:37 $
This page tracks issues raised between releases of Working Drafts of the
Techniques for Accessibility Evaluation and Repair Tools Document.
If there is an issue that is not on this list, or that is misrepresented or
inadequately summarized, please send your comments to w3c-wai-er-ig@w3.org or contact the
editor, Wendy Chisholm.
Table of Contents of All Issues
Open issues (WCAG)
Open issues (ATAG)
Open Issues (XTECH)
Closed Issues
Open Issues (WCAG)
- Check
applet and OBJECT for any HTML element, not just valid text.
- From: Leonard R. Kasday (kasday@acm.org) Date: Sun, Jan 23 2000
- Scope: Techniques 1.1.E and 1.1.F - 21 December
release
- Status: Discussed at the 31 January
telecon (minutes). Realized we need clarification from Len.
- Resolved: 15 January 2001.
- WCAG 1.0 says to follow specs, the HTML spec allows HTML within
OBJECT and APPLET, therefore we should check for it. Note that this
was resolved in the 26 April 2000 AERT Working Draft. However, it uses
an "or" (alt or content) WCAG HTML Techniques uses an "and" due to
some browsers that may support alt but not applet content.
- Open issue for WCAG HTML Techniques document.
- Text
equivalents for audio files do not have to be a text transcript file.
The text can be on the page in which the A element resides.
- From: Leonard R. Kasday (kasday@acm.org) Date: Sun, Jan 23 2000
- Scope: Technique 1.1.G - 21 December
release
- Status. 15 January 2001 - good example of testability issue. Useful for
user agent to be able to show the text equivalent rather than having
person hunt around in text. WCAG says provide an equivalent, but how find
it? WCAG issue - how do users or user agents find text equivalents?
- From: Leonard R. Kasday (kasday@acm.org) Date: Sun, Jan 23 2000
- Current
browsers don't render Q, so Q isn't usable today.
- Scope: Technique 3.7.A - 21 December
release
- Status: LK took this issue to WCAG list with proposed rewording to drop
Q element from the example for checkpoint 3.7. Still under discussion
- Proposal: If an element is not supported or not supported consistently,
"Warning: you are using a quote mark instead of Q, see WCAG for guidance."
Waiting on WCAG's final word. This was taken to WCAG (15
Jan - "Don't require <Q>"). Can we use this general approach for
other open issues as well?
- Discussion
of 11.4
- Scope: Checkpoint 11.4 - 21 December
release
- From: Wendy A Chisholm (wendy@w3.org) Date: Mon, Jan 24 2000
- Issues:
- When does a person receive a message about providing an alternative
page?
- What are some automatic checks that we can perform to determine if a
page as been identified as an alternative page is up to date?
- What action do we take if we identify/verify that an alternative
page exists?
- Status
- Proposals:
- To answer, "When receive a message?" Always, since even if
everything checks out it still could be made better.
- Until have more info from WCAG, show that message all the time.
- At this point, there are no actions to take to identify/verify that
an alternative page exists until have more info from WCAG. Also, no
automatic checks to propose yet.
- From: Leonard R. Kasday (kasday@acm.org) Date: Sun, Jan 23 2000
- Issue: "User
notification of style sheet use." A LINK element with a REL attribute
set to 'stylesheet' will generate this notification." Also: if tags have
style attribute set, or <STYLE> element is used.
- Scope: Technique - 21 December
release
- From: Leonard R. Kasday (kasday@acm.org) Date: Sun, Jan 23 2000
- Issue: Must
we insist on W3C technologies if there are other standards with good
accessibility? AFter all in the authoring guidelines we ask for
accessibility in the non-w3c technologies implementing the editor.
- Scope: Technique 11.1 - 21 December
release
- 15 January 2001 - WCAG 2.0 is heading in a direction that will allow any
technology that meets the XML Accessibility Guidelines, is a W3C
Recommendation, or has some indication that it has been designed with
accessibility features. WC Proposes to close this issue.
- If this issue is closed, then it should also close the issue associated
with technique
11.1.1 about how to check for W3C technologies.
- A page could flunk level A but have a text-only that passes AAA. There
ought to be a phrase in WCAG that says, "However, a page links to an
accessible page per checkpoint 11.4, the conformance level of the former
shall be the conformance level of that alternative page." Len
Kasday - 30 January 2000.
- We should help the author supply "hreflang" and "type" on A and AREA. Michael
Cooper - 24 January.
- However, 13.1 is a p2, and the "provide base language" checkpoint (4.3)
is a P3. Wendy
Chisholm (4 Feb 2000) proposes there are actually 2 checkpoints.
- Scope: Checkpoint 13.1
- How do we determine if a script creates a problem for accessibility?
Which functions do we look for?
- onmouseover
- href="javascript:"
- document.write
- others?
- In Technique 9.3.1 we suggest several repairs, but there is an open
question about what to do with onMouseMove.
- Status
- Discussed at 25 September
2000 telecon. Determined that this issue is still open. Len will
continue the discussion on the list.
The WCAG WG closed this issue at the 15 June 2000
telecon. The WCAG Techniques for HTML still needs to be updated to reflect
this decision. AERT/AU-TECHS should incorporate this decision once its
made.
The requirement for this technique (5.5.2) is left blank. The only guidance
that WCAG 1.0 gives is in the HTML Techniques document under "providing
summary information." I believe this is an open issue for WCAG to address
in the techniques documents. WCAG 2.0 (12 January 2001) version has a
checkpoint that says, "Summarize complex
information." Techniques and tests will clearly fit under this
checkpoint.
There is a question about creating
wrappers (either HTML or JavaScript) of dynamic content to make it
accessible in relation to FRAME and IFRAME elements. Also, "any actions that
change the display must change the equivalent @@Is this computable in a
practical time (cf. NP complete) . Computer science help needed here. Of
course, as in other parts of document, the fact that the equivalent changes is
no guarantee that equivalent is correct than it is guaranteed that
"alt"
text for an image is correct."
- Does this mean checking Java, Flash, etc? Can we only do this for
scripting? Or prompt the author to check? [Technique
6.4.1 April 2000 draft].
- While this is repair, I think it is an important issue for WCAG
scripting Techs to consider, then ATAG should incorporate repair into
ATAG-TECHS.
Currently, there is not text for Technique 6.5.2 [priority 2].
Need something for scripts and programmatic objects? is this covered by 6.3.1
(Verify that the page is usable when programmatic objects are disabled)? WC
believes that these are very different: 6.3 says that when scripts are not run
the page is still usable. 6.5 says that when scripts are run the page is
usable. Therefore, we need to create tests for ensuring that scripts are
accessible as well as pages are accessible when scripts are not run.
There is a suggested repair for script, but a question about content
included via OBJECT, EMBED, and APPLET elements. [Technique 7.3.2
April 2000 draft].
There is a placeholder in the repair for Technique
10.3.1 to include the heuristics used by tablin to create a linearized
version of a table.
It is unclear how to evaluate for this [Technique 11.3.1
April 2000 draft] . Perhaps this be handed off to the group working on
these techniques in WCAG?
Currently no suggestions for the following checkpoints.
27 July 2001 - WC proposes that most of these will be covered by the WCAG
2.0 success criteria, and that once defined by WCAG becomes an ATAG-TECHS
issue for how to automate/walk a user through.
Several of the appendicies are placeholders. Is the information available
somewhere and it just need to be gathered or is research required to fill
these in?
27 July 2001 - Believe these will be identified in the various WCAG
Techniques documents (primarily HTML).
- If an image map is both client-side with alt provided on links and
server-side, then don't need redundant text links for server-side.
15 January 2001 - ERT includes some detail that would be beneficial for
WCAG Techniques documents.
Open Issues (ATAG)
- We should also check EMBED and OBJECT for audio types (from sound
extension as source or a TYPE attribute); should also ask about APPLET,
EMBED, OBJECT, SCRIPT which may contain sounds we don't know about. Michael
Cooper - Mon, Jan 24 2000
- Scope: Technique 1.1.I - 21 December
release
- Proposal: 15 January 2001 - new technique needs to be added to
ATAG-TECHS/AERT.
- Related issue: If checking that something is audio, if it is script you
have to interpret the script. If it is a cgi you have to send a request to
the cgi/php/asp/etc. to determine what mime type is returned in the
header.
- Don't
limit to text description. Prompt for HTML that is functionally
equivalent. This may be, for example, a list of links, form input to CGI,
etc. From: Leonard R. Kasday (kasday@acm.org) Date: Sun, Jan 23 2000
- Check for just one. Placement on page may be arbitrary. Michael
Cooper - Mon, Jan 24 2000
- Scope: Technique 1.1.J - 21 December
release
- Proposal: 15 January 2001 - new technique needs to be added to
ATAG-TECHS/AERT.
- From: Leonard R. Kasday (kasday@acm.org) Date: Sun, Jan 23 2000
- The
ABBR should be pronounceable since the purpose is to be read by speech
technology in the future (cf.
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#data-tables )
- Scope: Technique - 21 December
release
- Proposal: There are text-to-speech techniques to determine if something
is pronounceable. We could direct people to these if they are not buried
in proprietary work? It is up to AU to determine feasibility of techniques
in the new document.
- From: Leonard R. Kasday (kasday@acm.org) Date: Sun, Jan 23 2000
- "If
any programmatic elements are found in the document, provide a user
notification." tool should include means to test the embedded
technologies, e.g. java, at least by running them, preferably by including
any test software supplied for the technology.
- Scope: Technique 8.1.A - 21 December
release
- Proposal: Suggest to AU to add a non-normative suggestion to do further
testing if you can, but we don't know what it is now. There is testing you
could do, once inside the language. For example looking for Java classes
that support the accessibility interfaces and classes, or looking for
specific elements and attributes within SMIL for captions.
- We've talked about ways this might be done when checking several pages
across the site. Do we want to put into this Techniques or wait for later?
Michael
Cooper - Mon, Jan 24 2000
- Scope: Checkpoint 13.3
- Proposal for ATAG-TECHS: We can not automate the evaluation. However,
some of the repairs could be automated. For example, a table of contents
of a document may be created by pulling together headers or a site map
could be created by a robot that crawls all of the links.
In the AERT the issue is, "how can we determine if text should be marked up
as a quote?" One suggestion is "lots of emphasized text." There is a question
about how many words. This seems to be an ERT/ATAG issue, but one that would
require some research to determine a limit on the number of words.
We have been unable to determine what the appropriate OBJECT type="??" for
applets and other programmatic objects. Refer to technique
6.2.2 in the April 2000 draft. This also applies to techniques 6.3.1 and
6.4.1.
First technique checks for META, ADDRESS, TITLE
and
LINK
elements. Should there be a separate one for RDF [Technique 13.2.2]?
Checkpoint
14.3requires looking across the site. Do we need to suggest two levels of
checking? 1. between page or site-wide 2. within pages?
Open Issues (XTECH)
- From: Leonard R. Kasday (kasday@acm.org) Date: Sun, Jan 23 2000
- Issues:
-
- Scope: Technique 1.3.A - 21 December
release
- Proposal: 15 January 2001
- Multimedia definition to be handled by the cross-guidelines
glossary.
- WCAG Core Techniques says that multimedia can be handled by text in
the document therefore no proposed changes. Related to
issue #13.
- Priorities
From: Wendy A Chisholm (wendy@w3.org) Date: Sun, Jan 23 2000
- Chris
Ridpath: Techniques should inherit from checkpoint. 1.1.K was a
typo.
- Check
applet for "alt" always needed? "APPLET element must have a valid ALT
attribute." Is this needed if the user, in accordance with 1.1.E, has code
before </applet> that shows up when user agent skips applets?
- From: Leonard R. Kasday (kasday@acm.org) Date: Sun, Jan 23 2000
- Scope: Technique 1.1.D - 21 December
release
- Status: Resolved at the 31 January
telecon (minutes). Yes, we should prompt for alt even if text in
APPLET
- From: Leonard R. Kasday (kasday@acm.org) Date: Sun, Jan 23 2000
- User
notification for appropriate markup language. Since this checkpoint
only refers to images, why notify for all BODY Elements? Why not just
Images? Also, I don't understand what "All body elements" mean. There is
just one "Body Element" since that term means the start tag, end tag, and
everything in between. Do you mean all elements that are part of the Body
Element's content?
- Scope: Technique 3.1.A - 21 December
release
- 15 January 2001 - seems to have been resolved. Technique 3.1.1 seems to
have incorporated these issues.
- From: Leonard R. Kasday (kasday@acm.org) Date: Sun, Jan 23 2000
- "User
notification of dynamic content changes." A SCRIPT elements will
generate this user notification also, any Javascript, e.g.
onmouseover=".... code which changes something somewhere..."
- This also applies to:
- User notification of usability when programatic objects are
disabled
- User notification of device independent event handlers.
- Scope: Technique - 21 December
release
- Resolved: this is fixed in the April 2000 version.
- Title
of the techniques document
- From: Wendy A Chisholm (wendy@w3.org) Date: Mon, Jan 24 2000
- Scope: General - 21 December
release
- Proposals
- Techniques for evaluation and repair of Web content
- Evaluation and Repair tool accessibility guidelines
- Techniques for automatic implementation of the Web Content
Accessibility Guidelines
- Techniques for evaluation and repair of *accessible* web
content
- Techniques for Accessibility Evaluation and Repair Tools
- Raised during
18 September 2000 telecon: priorities for techniques is an interesting
idea. Wonder if applies across the document. P1 less heuristics, P2 more
heuristics, P3 all heuristics.
- Status 15 January 2001 - this issue will have to be discussed in
conjunction with AU. Len sent a message to the AU list asking about the
implications of AERT being incorporated into a normative document where
until this point it has been informative (18
Jan 2001 - Priorities of AERT techniques).
- Resolved: ATAG techniques, which is where AERT is incorporated is
non-normative, therefore no worries. (18
Jan 2001 - CMN response).
In the AERT the issue is, "is this handled by technique 13.1.1". WC thinks
it is and proposes the issue be closed. 15 January 2001.
$Date: 2004/01/13 23:01:37 $ Wendy
Chisholm