- From: Ian Jacobs <ij@w3.org>
- Date: Sun, 09 Apr 2000 14:03:52 -0400
- To: w3c-wai-ua@w3.org
Hello Working Group,
I've updated the issues list [1] with issues raised during
the Proposed Recommendation review of the Guidelines [2].
Notes on the issues:
1) Seventy issues were raised. While that may be intimidating,
on review I'm convinced that most of them only
require clarifications to the document. While we need to
consider each issue, I think that we can address most of them
very quickly in our meeting.
2) For most of the checkpoints, I have proposed a resolution
(some of them conceived with Charles as well). These proposals
are only meant as starting points for discussion.
3) Issues 253 through 276 were not raised in a formal review
and so, strictly speaking, we are not required to address them
in order to advance. However, I think that we should consider
them as some of them are quite important. We should examine these
after the other issues to ensure that we finish the "official"
list first. (Actually, issues 207 through 211 were also raised
by the WG, not the AC, and we should also consider those.)
I have quoted below all the PR issues. The online version is more
accessible (with links, etc.).
Thank you,
- Ian
[1] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html
[2] http://www.w3.org/TR/2000/PR-UAAG10-20000310
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
BEGIN LIST OF PR ISSUES 276 through 207 (reverse order).
Issue 276 (Proposed Recommendation): Guideline 2: Additional advantage
of standard APIs
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:40:39 2000
Category of issue: Editorial
Type of issue: Guidelines
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
The introduction to Guideline 2 says that using the standard APIs
for supported devices "allows assistive
technologies to operate the user agent programmatically by
simulating events from a mouse, keyboard, pen, or
other input device." I would add that an additional benefit is that
this allows aids to monitor and/or intercept the
input. IJ Proposed: Adopt suggested additional text.
Key References: none
Issue 275 (Proposed Recommendation): About relative importance of
"consistency" to accessibility.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:39:35 2000
Category of issue: Editorial
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
In the introduction, the paragraph with "Furthermore, it is
important to maintain consistency" gives the wrong
impression. The words clearly and correctly state that
functionality and usability are more important than
consistency, but the order and amount of space given to consistency
strongly conveys the opposite message.
Proposed IJ: Adopt suggestion.
Key References: none
Issue 274 (Proposed Recommendation): Contextual and direct access not
explained in document.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:38:34 2000
Category of issue: Editorial
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
IJ Proposed: They are, but in the introduction. Should be moved to
definitions. Editorial.
Key References: none
Issue 273 (Proposed Recommendation): Checkpoint 10.9: Why graphical
controls only?
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:35:38 2000
Category of issue: User Interface Accessibility
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Great feature, but why is it limited to graphical controls? Is it
not equally important to allow rearranging textual
controls, such as menu titles and toolbar buttons with textual
labels? CMN: Priority of text controls less important
since designed for users with CD (but a good catch anyway). IJ: I
would have assumed that text labels were
included in this requirement since if they don't follow their
controls, then that would be even more confusion.
Also, I believe this is referring to all controls of a graphical
user interface.
Key References: none
Issue 272 (Proposed Recommendation): Checkpoint 8.8: Why doesn't this
include navigation?
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:33:43 2000
Category of issue: Navigation
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
It seems strange to include this and not include a Pri 3
recommendation that the user be able to navigate in the
outline, and ideally be able to use that method to navigate to the
corresponding location in the non-outline view.
IJ Proposed: That is covered by structured navigation requirement.
Key References: none
Issue 271 (Proposed Recommendation): Checkpoint 4.7: Change to P2 since
arbitrary repositioning not a
requirement.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:30:49 2000
Category of issue: User-control of Style
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
This seems like Pri 2 instead of Pri 1 to me, because it is not
reasonable to require the user to be able to move
captions to any arbitrary location. Most media players don't
support moving the captions to arbitrary locations,
and I see lack of this feature as making things difficult but not
impossible. CMN: A problem arises under
magnification, zooming for languages that do not have text flow
(e.g., SVG).
Key References: none
Issue 270 (Proposed Recommendation): Checkpoint 2.5: Need clarification
of why in UI division?
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:29:02 2000
Category of issue: Editorial
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
IJ Proposed: All checkpoints in G2 should be for content, not UI.
Editorial change.
Key References: none
Issue 269 (Proposed Recommendation): Checkpoint 2.3: Should this be P1?
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:27:12 2000
Category of issue: Alternative content
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
If the author failed to provide alt text for graphical links, the
user may not be able to use the page effectively
unless the UA provides some information about the links, such as
their link destinations.
Key References: none
Issue 268 (Proposed Recommendation): Applicability provisions need
review (Part IV)
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:25:56 2000
Category of issue: Editorial
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
The definition of "applicability" says that "a checkpoint (or
portion of a checkpoint) applies to a user agent
unless..." would be less ambiguous if it added "unless at least one
of the following are true." IJ Proposed: Adopt
proposal.
Key References: none
Issue 267 (Proposed Recommendation): Checkpoint 11.2: Use relative
priority rating.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:24:15 2000
Category of issue: Conformance
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Technically I think the priority of documenting a feature is the
same as the priority of providing that feature. The
Web Content guidelines use such linkages. For example, it should
not be a Pri 1 requirement that you document
Pri 3 features: the fact that the feature is only Pri 3 means the
user does not really need it, and thus failing to
document it won't make it "impossible" for users to access the Web.
CMN Proposed: The WG intentionally did
not choose a relative priority rating for this and other
checkpoints related to Web content. In this case, knowing
the featureis there is critical to being able to learn to use the
tool.
Key References: none
Issue 266 (Proposed Recommendation): Checkpoint 7.3: Add a checkpoint
for navigation of non-active elements.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:23:13 2000
Category of issue: Navigation
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
IJ Proposed: This is covered by structured navigation requirement.
Key References: none
Issue 265 (Proposed Recommendation): Checkpoint 7.2: Lower priority from
P1 since convenience, not necessity.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:20:49 2000
Category of issue: Orientation
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
I cannot justify this being priority 1, because although it
certainly makes access easier and more convenient, the
lack of it does not prevent use of the Web content. IJ Proposed: It
is disorienting for users with CD, or who are
blind or accessing information serially. I can see that it doesn't
prevent access to content, however, it may make
it near impossible for some users (e.g., with short-term memory
problems) to locate where they were.
Key References: none
Issue 264 (Proposed Recommendation): Checkpoint 3.9: Raise priority
since may cause CD problems.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:18:17 2000
Category of issue: User-control of Style
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
[This checkpoint] seems like it should be Pri 1 or 2 instead of Pri
3. That is because images can be extremely
distracting for users with some cognitive disabilities, who may
need to have them replaced by the text in order to
be make the page useable. (It also seems a bit strange that letting
the user turn off images is Pri 3 but letting
users choose to see the alternative text is Pri 1.) IJ Proposed:
The WG decided that background images were
more distracting than other images. Hence two different
checkpoints. CMN Proposed: This is just a special case
of 2.5 since an image is an alternative to its text equivalent.
Key References: none
Issue 263 (Proposed Recommendation): Checkpoint 8.1: Change to P2 since
programmatic access probably most
important and covered elsewhere.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:16:14 2000
Category of issue: Tables
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
I would categorize this as Pri 2 rather than Pri 1. Blind users may
need this information but that means making it
available programmatically for use by their screen reader should be
sufficient, and that is already covered in
checkpoint 5.1 ("Provide programmatic read access to HTML"). If the
UA provides its own UI to display this
information directly to the user, that would only benefit blind
users running "older" screen readers that fail to take
advantage of technological innovations such as the DOM and MSAA.
Also, any UI for this it probably won't be
usable with the keyboard unless they allow navigation to non-active
content, and that is not even a Pri 3
recommendation at this point.
Key References: none
Issue 262 (Proposed Recommendation): Checkpoint 5.9: Change Priority
since non-standard approaches may be
better.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:12:44 2000
Category of issue: OS Conventions
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
"Follow operating system conventions and accessibility settings. In
particular, follow conventions for user
interface design, default keyboard configuration, product
installation, and documentation." I'm all in favor of
consistency when it is appropriate, but I cannot justify this being
a Pri 2 requirement. I would find it acceptable if
the UA provides equivalent functionality through other means,
especially one that is more accessible than the
system standard. For example, if a UA provides an entirely
automated installation using a batch file, or a product
for blind users provides a self-voicing installer, those might be
more accessible than using the system installer
and I would find them an acceptable and even laudable approach. I
am hoping that the authors really meant
?Follow operating system conventions for accessibility? and did not
mean to include every mainstream
operating system convention. If so I would recommend clarifying the
wording. CMN Proposed: There are
accessibility conventions that amount to the software equivalent of
an alternative page. For example, editing a
batch script to run the installation. I agree with GL's proposal
"Follow operating system conventions for
accessibility" and consider this an editorial clarification.
Key References: none
Issue 261 (Proposed Recommendation): Checkpoint 1.3: Require
clarification of scope of checkpoint.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:06:41 2000
Category of issue: Device Independence
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
"Ensure that the user can interact with all active elements in a
device-independent manner," seems overly
broad. What is the real goal? I doubt it is that everything,
including text input, needs to be supported using the
alone mouse. Does it also imply that if voice input is supported
for dictation it also needs to be supported for
command-and-control? Or is the real intent just "make sure every
active element can be navigated to and
manipulated using the keyboard," which is mostly redundant to other
checkpoints. Proposed CMN: Implies that
active elements, command and control, etc can be done through
keyboard, voice (using an appropriate API),
etc. A particular failing of most user agents here is to buy the
HTML mouse-specific event model for creating
active elements and not allow that to be done except with a mouse.
Key References: none
Issue 260 (Proposed Recommendation): Guideline 1 checkpoint language
unclear.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:04:26 2000
Category of issue: Editorial
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Unclear what "input device API" and other similar references in G1
checkpoints mean. It sounds like the user
needs to be able to input text through the mouse API, and that any
UA that supports voice input for dictation or
for command-and-control is required to support voice input for
both. IJ PRoposed: Editorial clarification
required. The note in 1.1 was supposed to indicate that the user
agent was not required to provide for text input
through the mouse.
Key References: none
Issue 259 (Proposed Recommendation): Applicability provisions need
review (Part III)
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:01:42 2000
Category of issue: Conformance
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
[Applicability] includes an exemption for "requirements about a
content type (script, image, video, sound, applet,
etc.) that the user agent either does not recognize or recognizes
but does not support natively." [That seems to
be a blanket exemption for a user agent that may use the operating
system's own features to accomplish a task
instead of implementing natively.] IJ Proposed: Yes, this is the
intention. However the UA must ensure that OS
features used are accessible. No change is required since this is
stated in the applicability section.
Key References: none
Issue 258 (Proposed Recommendation): Unclear what information through UI
and what through API
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 12:00:33 2000
Category of issue: Assistive technology compatibility
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
In some cases it is unclear when the UA must expose information
directly to the user (by providing UI to show
the information on the screen, etc.) and when the UA can simply
expose the information programmatically (such
as through the DOM). This should be clarified by stating that in
all cases the information should be exposed to
the user directly through the UI except where the wording
explicitly says that the information may be exposed
programmatically. IJ and CMN Proposed: Adopt suggestion.
Key References: none
Issue 257 (Proposed Recommendation): Difficult to know when a UA has
conformed.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 11:57:45 2000
Category of issue: Conformance
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Not clear what is required for conformance and what is optional.
The Techniques document doesn't help it fails
to distinguish between (a) background information (such as
"Allowing the user to?will benefit individuals with?"),
(b) techniques required for meeting the guideline (such as ?When
changing the rate of audio, avoid pitch
distortion?), and (c) optional recommendations that can improve the
usability or functionality of the product when
addressing the guideline (such as ?If buttons are used to control
advance and rewind, make the
advance/rewind distances proportional to the time the user
activates the button.?). IJ Proposed: The Guidelines
must allow for flexible interpretation and evolutions in solutions
and technologies. The Techniques Document
may be improved with better classifications and even (though this
needs to be discussed) statements such as
"this technique is sufficient to satisfy the requirement of the
checkpoint".
Key References: none
Issue 256 (Proposed Recommendation): Applicability provisions need
review (Part II)
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 11:56:00 2000
Category of issue: Conformance
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
The exemption when requirements "cannot be satisfied due to
hardware or system resource limitations" could be
interpreted as giving any hardware manufacturer the right to cut
costs on hardware by leaving off key
accessibility components and still earn Triple-A compliance. For
example, could a Web appliance that only
supports touchscreen input earn the same level of compliance as one
that included a broader range of
hardware and so supported a broader range of users? Proposed IJ:
This is a real issue. We don't want to
require APIs and multi-modal support for all devices. But this may
mean that those devices are not accessible
(e.g., they only have a touch-screen input, visual output, and no
infrared connection/API. What to do in these
cases?
Key References: none
Issue 255 (Proposed Recommendation): Applicability provisions need
review.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 11:51:28 2000
Category of issue: Conformance
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
- Unclear that keyboard support is required (implication that "if
supported, must be supported accessibly. IJ
Proposed: This is required explicitly by checkpoint 1.2, so only
clarification required. - Need to clarify that
exemptions only apply to the entire UA, not pieces. For example,
the UA couldn't claim exemption for keyboard
access to forms just because it chooses not to support the keyboard
there. IJ Proposed: Yes. Add a statement
to the section on applicability about this.
Key References: none
Issue 254 (Proposed Recommendation): Checkpoint 4.1: Does zoom really
meet requirement of text size control?
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 11:49:26 2000
Category of issue: User-control of Style
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
[Does] a simple zoom feature meets the high-level goal of this
checkpoint, which is to give the user greater
control over the display of font sizes? In particular, the user
should be able to cause all fonts to be displayed at
a user-selected size, and have the text wrap accordingly. By
contrast, a zoom feature that makes small text
large will make large text so huge that the page may be unusable.
CMN Proposed: - This comment is true for
some languages, but not for all, e.g., SVG, which doesn't have
wrap. - In certain specs, you are required (thus
6.2) to implement font size changes. In other cases, zoom may be
the only solution. - Might add a
cross-reference to 6.2
Key References: none
Issue 253 (Proposed Recommendation): Checkpoint 1.2: Clarification about
different layers of APIs required.
Name: Other comments (not formal AC Review)
Source URL: None
Date: Sun Apr 9 10:26:05 2000
Category of issue: Device Independence
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
The requirement should be the higher-level goal of allowing
accessibility aids to monitor and record all the
output being doing by the UA, and the UA should be able to comply
by EITHER (a) drawing to the screen with
standard output API, or (b) explicitly exposing their screen
content through a documented, supported API. IJ
Proposed: Since there may be more than one standard API for an OS,
change "Use the" to "Use a". Should we
add examples of standard APIs we expect to be used on different
platforms?
Key References: none
Issue 252 (Proposed Recommendation): Conformance mechanism should allow
more granularity
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 10:19:16 2000
Category of issue: Conformance
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
A more granular or incremental approach to conformance levels and
conformance icons would allow [some]
applications to more effectively signal the accessibility services
that they do provide, and would encourage
formal participation by a broader range of software [developers].
IJ Proposed: The WG has considered many
possibilities for conformance and chose this one. Please refer to
summary of conformance discussions,
including a proposal for checklist-level conformance and why it was
not considered adequate. Refer also to
other conformance-related issues and their resolutions. Summary by
Ian:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0433.html
Key References: none
Issue 251 (Proposed Recommendation): Checkpoint 11.5: Req should be to
document changes that affect
accessibility.
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 10:05:30 2000
Category of issue: Documentation
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
"Document changes that affect accessibility between software
releases." IJ Proposed: Agreed. However, it must
be made clear that there are many changes that affect
accessibility, including all of those features discussed in
this document. The difficulty is how do the authors of the
documentation realize what affects accessibility?
(Proposed answer: Read WAI Guidelines).
Key References: none
Issue 250 (Proposed Recommendation): Checkpoint 8.3: Delete, since
covered elsewhere.
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 10:02:08 2000
Category of issue: Navigation
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
[This] should not be a checkpoint, but moved to a technique for
Ckpt 6.2 "use appropriate W3C
recommendations". IJ Proposed: WG chose to make some checkpoints
stand out due to importance and to label
them as important special cases.
Key References: none
Issue 249 (Proposed Recommendation): Checkpoint 4.7: Change to P2 since
no reference implementation
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 10:00:17 2000
Category of issue: Conformance
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Similar comment made in issue 244 Proposed CMN: Since CSS 2
positioning allows this for HTML and XML
applications, this suffices.
Key References: none
Issue 248 (Proposed Recommendation): Checkpoint 4.2: Change to P2
because 4.1 is P1.
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:57:35 2000
Category of issue: User-control of Style
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
[S]hould be a priority 2 (not a priority 1) because selecting a
larger size is covered in checkpoint 4.1 IJ
Proposed: Size is only one issue here. People may not be able to
read a Gothic font. Question: Is this a general
usability issue or an accessibility issue? The same goes for very
small fonts: I may be able-bodied and still not
be able to read the text.
Key References: none
Issue 247 (Proposed Recommendation): Checkpoint 2.5: Scope of choice
limited to what UA can recognize
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:53:33 2000
Category of issue: Alternative content
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
[E]xplain that in-line prose should not be considered an equivalent
alternative that the user could choose to not
view. See the definition of "equivalent alternative" that is used
in checkpoint 2.5 IJ Proposed: Yes, this is a
clarification. Refer also to issue 207 on checkpoint 2.1 - If the
scope of 2.1 is reduced to alt equivalent, this
needs to be made clear in general.
Key References: none
Issue 246 (Proposed Recommendation): Checkpoint 2.3: Editorial change to
align with 2.1
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:52:21 2000
Category of issue: Editorial
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Change "... make available to other..." to "... ensure that the
user has access to other ..." so that it matches the
wording in checkpoint 2.1 IJ: Editorial. Refer also to issue 207
(on checkpoint 2.1 scope).
Key References: none
Issue 245 (Proposed Recommendation): Checkpoint 1.5: Change scope to all
UI components.
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:50:28 2000
Category of issue: User Interface Accessibility
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Change "message (e.g., prompt, alert, etc.)" to "user-interface
object (e.g., prompt, alert, button, etc.)" IJ
Proposed: The WG expressly did not include the entire user
interface (covered by checkpoint 5.9, a P2).
However, if adopted use the term "component".
Key References: none
Issue 244 (Proposed Recommendation): Checkpoint 4.5: Change to P2 since
no reference implementation.
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:41:55 2000
Category of issue: Conformance
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
IJ Proposed: The applicability clause works here: if there is no
specification that allows this, not required.
Otherwise, falls into 6.2. Just because someone hasn't implemented
a specification doesn't mean they shouldn't
be required to. CMN Proposed: Priorities based on user needs, not
reference implementations
Key References: none
Issue 243 (Proposed Recommendation): Checkpoint 9.2: Change to P3 since
usability, not accessibility issue.
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:39:08 2000
Category of issue: Conformance
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
This is not an accessibility issue, but a general usability issue
and therefore should be a priority 3. In some
cases it would be appropriate automatically submit on a single
mouse click. IJ Proposed: Form submission
without user awareness may be disorienting to users who are blind
or have CD. A usability issue for some (and
clearly it makes the document easier to use for some) but an
accessibility issue for others.
Key References: none
Issue 242 (Proposed Recommendation): Checkpoint 7.6: Minimal requirement
for structured navigation?
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:34:34 2000
Category of issue: Navigation
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Unclear what the minimum requirement is. Does providing
programmatic access to the DOM suffice? IJ
Proposed: Minimal requirement is element-by-element navigation,
i.e., navigation of the document object.
Programmatic access does not suffice - this is a requirement
through the UI.
Key References: none
Issue 241 (Proposed Recommendation): Checkpoint 2.1: Minimal requirement
- Is source view ok for some cases?
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:30:08 2000
Category of issue: User Interface Accessibility
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Source view as a technique should be considered to meet the
requirement of the checkpoint for some cases
(e.g., the "title" attribute). User agent developers may do better.
IJ Proposed: Need to address minimal
requirement for conformance. The Working Group seems to clearly
feel that a source view does not meet the
requirements of the checkpoint (e.g., since users are not asked to
read markup or binary encodings). Refer also
to issue 207
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#207
Key References: none
Issue 240 (Proposed Recommendation): Guideline 11 rationale: Add power
users to list of those who benefit.
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:20:20 2000
Category of issue: Editorial
Type of issue: Guidelines
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Not imperative but to demonstrate this guideline's broad
applicability you may want to add power users to the
laundry list. IJ Proposed: Adopt suggestion.
Key References: none
Issue 239 (Proposed Recommendation): Checkpoint 10.6: Clarification of
example required.
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:13:23 2000
Category of issue: Editorial
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
"... if a functionality is available from a menu, the letter of the
key that will activate that functionality is underlined..."
I assume you are talking about mnemonics. With them the underlining
only occurs within the menu or in the area
you are directly interacting with (e.g. a dialog box) and they must
be explicitly set by the developer. The wording
makes it seem like the underlining occurs someplace other than
where the command or setting is actually set by
the user plus it reads like the setting of them happens
automatically. I recommend rewording of the example. IJ
Proposed: For example, on some operating systems, when developers
specify which command sequences will
activate which functionalities, standard user interface components
display those bindings to the user. For
example, if a functionality is available from a menu, the letter of
the activating key is underlined.
Key References: none
Issue 238 (Proposed Recommendation): Checkpoint 10.5: Problem of
single-key in edit mode.
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:11:32 2000
Category of issue: Editorial
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
"Allow the user to configure the user agent so that the user's
preferred one-step operations may be activated
with a single input command" This will be problematic in a text
area or region because it will consume the single
keystroke if the command is invoked by an alpha-numeric key press.
Perhaps the following should be tacked
onto the end "... single input command when the focus is outside a
text input region (..." IJ Proposed: Add a Note
that in text entry mode, this functionality is not expected.
Key References: none
Issue 237 (Proposed Recommendation): Checkpoint 10.2: Clarification of
scope required.
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:08:51 2000
Category of issue: Keyboard
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
I assume "mobility access keyboard modifiers" means AccessPak,
AccessX, EasyAccess (can't check
techniques to verify, the site keeps killing my browser). If so,
perhaps a definition of "mobility access keyboard
modifiers" should be in the glossary. Does this also cover things
like the use of I/O ports? Shouldn't it also cover
mnemonics, accelerators (aka AccessKey I believe), and in general
the platform UI's keyboard navigation
sequences?
Key References: none
Issue 236 (Proposed Recommendation): Guideline 9: Add "through standard
API"
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:06:24 2000
Category of issue: Editorial
Type of issue: Guidelines
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
In opening description - "User agents must ensure that
notifications are available in an output device
independent manner." How about adding "... thru a standard
programmatic interface." after manner? See
Checkpoint 5.7 discussion for why. IJ Proposed: Add cross-ref to
5.7, which should include note about how the
checkpoints for APIs apply to other checkpoints.
Key References: none
Issue 235 (Proposed Recommendation): Checkpoint 8.1: Is there support
for table summary information?
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:03:20 2000
Category of issue: Editorial
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
"Make available to the user the author-specified purpose of each
table ..." Does HTML support this? [Does the
techniques document] say how to support this? Is it a bunch of D
description links? IJ PRoposed: Add
CAPTION and summary as examples. Note also that this is a special
case of both 2.1 and 6.2. IJ Proposed: Add
explanation in section 1.3 of document that some checkpoints are
important special cases of one another or of
several different checkpoints. They are included to make the
requirement explicit.
Key References: none
Issue 234 (Proposed Recommendation): Guideline 8 rationale mentions
issue not in G8 checkpoints.
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 09:01:54 2000
Category of issue: Editorial
Type of issue: Guidelines
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
In the opening description - "Proportional scroll bars on graphical
..." Whatever is mentioned in the opening
description should have at least one associated checkpoint under
it, this one doesn't. The other bullets do
however. This should have one, be removed, or be moved (with a
checkpoint or 2) to Guideline 5. IJ Proposed:
This is part of checkpoint 9.4 and the requirement should be moved
to G9.
Key References: none
Issue 233 (Proposed Recommendation): Checkpoint 7.6: What does
"structure" mean here?
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:58:53 2000
Category of issue: Definition
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
"Allow the user to navigate according to structure." Does structure
just mean text or can it be more? This should
be clarified. Should the definition of structure be added to the
glossary? IJ Proposed: Identify structure as
document object (to be defined in a separate proposal). Note that
it could also be interesting to navigate by
semantics, but this would have to be addressed elsewhere (e.g.,
metadata that provides a navigation order or
links documents).
Key References: none
Issue 232 (Proposed Recommendation): Why are ATs considered UAs in this
document?
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:54:28 2000
Category of issue: Scope of Guidelines
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
It's confusing to me that assistive technologies (AT) are
considered UAs in the context of this document.
[Guideline 7] adds to my confusion. AT of the type highlighted in
this document does not act by itself in
"displaying" web content but instead, as noted in the doc, works
with other UAs. AT can and do for product
distinguisher reasons provide some of their own navigating
mechanisms, as screen readers and magnifiers do,
but they don't provide all that the user needs (they only do some
of what is highlighted in this guideline). Instead
they mostly tap into and take advantage of functionality provided
by the platform's UI toolkit and custom
components used in the UA the AT is interacting with. By placing AT
in the UA category in this document, does
that mean the AT and UA developers should both be supplying the
same navigation methods? If no, where
should the line be drawn and what checkpoints need to be added to
make that clear for developers? I ask
because while it may be appropriate for something like the HPR to
be put under the scrutiny of these guidelines,
ATs of the type highlighted in these guidelines shouldn't have to
be - they're interacting with the information and
functionality that came to the UA they are paired with. I agree in
the broader sense that an AT is a user agent
but for this document I don't think they should be clumped
together. Or AT, for this document, should be defined
as HPR, Opera, or some other technology that is specifically
focused on web content. IJ Proposed: We may
need to make clearer that this document's requirements are not
intended for "dependent" UAs (though they
could try to conform if they wished) To do this: - Clarify how UAs
in general and ATs are meant to interact. -
Refer to dfn of UA in UA responsibilities.
http://www.w3.org/WAI/UA/2000/03/ua-resp-20000308
Key References: none
Issue 231 (Proposed Recommendation): Guideline 6: In Guideline
rationale, identify scope of W3C and non-W3C
reqs
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:52:29 2000
Category of issue: Editorial
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
I started down a comment path thinking this guideline was meant to
cover W3C -and- non-W3C specs (e.g.
Java and Java Accessibility). It finally occurred to me that this
was meant to cover only W3C specs.... [H]ow
about something like "Implement W3C's accessible specifications."
If this whole guideline is meant to cover all
specs for technology that might be used in the content of a web
page then perhaps a specific set of statements
should be made in the opening guideline description or a guideline
added that says something like "If you don't
use a W3C technology/spec then make sure it can support accessible
design." This would mean, I'd imagine,
providing Plugin support and suggesting the technology/spec
developers make accessible content development
and display possible in their technology thru a standard interface
somehow. IJ PRoposed: Adopt suggestion.
Key References: none
Issue 230 (Proposed Recommendation): Checkpoint 5.9: Clarification on
default keyboard configuration
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:51:08 2000
Category of issue: Editorial
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Does default keyboard configuration mean look at style guide
recommended key sequences for accelerators and
things, Qwerty vs Dvorak vs ?, both, or more? It should be clearer.
Key References: none
Issue 229 (Proposed Recommendation): Checkpoint 5.9: Examples of
accessibility settings?
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:49:41 2000
Category of issue: Editorial
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
What are some examples of accessibility settings? Some should be
highlighted under this checkpoint in this
doc, not just in techniques. IJ Proposed: Add examples.
Key References: none
Issue 228 (Proposed Recommendation): Checkpoint 5.7: Use a standard API
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:47:07 2000
Category of issue: Editorial
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Add "thru a standard (or centralized?) programmatic interface"
after "...interface controls..."? I suggest this
because putting this information in a central location, as an
accessibility API does, makes it easy for the
assistive technology vendor to find and support access to this in
their product. It also generally means that the
way the notification is exposed won't change between dot releases
of the UA or platform it runs on (i.e. the
accessibility API won't change) IJ Proposed: This is covered by
checkpoint 5.5. Propose to add a note to
guideline 5 that explains (as is done in 1.1) that these
checkpoints apply to each other, and to any API
described in the document.
Key References: none
Issue 227 (Proposed Recommendation): Checkpoint 5.5: Add "where
available" to note
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:44:00 2000
Category of issue: Editorial
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Because an accessibility API is so powerful how about adding it to
this example with a "where available"
caveat? IJ Proposed: Instead, change "ensure that assistive
technologies have access" to "provide access to".
Don't add "where available since covered by applicability. (Or add
cross-ref).
Key References: none
Issue 226 (Proposed Recommendation): Clarify "content accessibility" and
"ui accessibility" split
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:38:55 2000
Category of issue: Editorial
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
The "content" portion of the UA is part of the "user interface"
(the 2 section names used to separate the
guidelines into logical areas). It might be good to change "user
interface" to "chrome" (with an accompanying
definition defining what chrome means - it's everything that
doesn't display page author generated content)
unless "user interface" truly does also include "content" related
checkpoints. If the later is the case, perhaps a
third section name should be added called "mixed" or something
which is meant to denote that the checkpoints
apply to both the "content" portion and "chrome." The "content
accessibility" title isn't quite right either. It reads
like something more appropriate in the Web Content Accessibility
Guidelines. Since this really, I believe, applies
to the content parser how about changing "content accessibility" to
"content parser accessibility" or "content
view generator accessibility" or something? IJ Proposed: - This is
part of review of definition of "content" (raised
as part of issue 207) - Editorial clarification required, notably
for G5.
Key References: none
Issue 225 (Proposed Recommendation): Checkpoint 4.16: Does UA have to
fire event for window changes?
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:37:15 2000
Category of issue: Assistive technology compatibility
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Is the UA responsible for firing off an event that can be picked of
by an assistive technology saying this has
occurred? It should but I'm not sure if this is stipulated
elsewhere in the guidelines. IJ Proposed: Yes, this is
covered by by 9.3 (notification of events). Proposed to add
cross-ref
Key References: none
Issue 224 (Proposed Recommendation): Checkpoint 4.16: Minimal
conformance requirement unclear
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:35:43 2000
Category of issue: Conformance
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Does this mean allow the user to configure it so it can open with
or without focus, minimized, ...? IJ Proposed:
WG should identify minimal requirement.
Key References: none
Issue 223 (Proposed Recommendation): Checkpoint 4.15: Does this include
focus rendering?
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:33:57 2000
Category of issue: User Interface Accessibility
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Does this include or mean how focus indication looks in keyboard
navigation (e.g. the focus indicator or box on a
link or active zone of an image map can be fat, skinny, dotted, ...
and/or what the input cursor looks like in a form
field)? IJ Proposed: No it doesn't. "How it looks" is covered by
4.13 (focus highlight). We could add a cross-ref.
Key References: none
Issue 222 (Proposed Recommendation): Checkpoint 4.11: Use of OS or
user-provided speech synth.
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:31:13 2000
Category of issue: OS Conventions
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Same as issue 22.1 The added twist is that the platform might
provide it's own speech synthesizer (and controls
for it) plus the user can also plug in and control their own
hardware based speech synthesizer. IJ Proposed: If
the UA is using the OS features, then it's the UA's responsibility
that the OS features are accessible. If the user
is using a different synthesizer (and assistive technology), it's
not the UA's responsibility.
Key References: none
Issue 221 (Proposed Recommendation): Checkpoint 4.8: Does UA need to
provide redundant audio controls?
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:28:55 2000
Category of issue: OS Conventions
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
What if the UA is only meant to run on platforms which have there
own facilities for volume control? For example,
Solaris, Windows, and Mac provide platform level audio controls.
Does the UA need to provide redundant
controls that perform the same function or can the UA punt the need
in situations where redundancy is known
(i.e. the platform has audio controls already)? The answer should
be made clear. IJ Proposed: No. The UA can
use what the OS provides (we say this already). Therefore, just add
clarifying note.
Key References: none
Issue 220 (Proposed Recommendation): Checkpoint 4.5: In control of rate,
must tracks remain synchronized?
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:26:19 2000
Category of issue: Multimedia
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
This may not be an issue given how multimedia such as video and
perhaps animation inherently work but
synchronization of multiple tracks is important. For this
checkpoint it doesn't say that when one multimedia
channel slows (e.g. the visual track of video) the other channel
should slow at the same rate. Should it say all
channels need to stay synchronized? Should the user be able to slow
or speed one track while letting others
stay at normal rates? It's not clear. IJ Proposed: Yes, they must.
This is covered by a piece of 2.6 and also by
6.2 if it involves respecting sync cues.
Key References: none
Issue 219 (Proposed Recommendation): Checkpoint 4.1: font family info in
note should be in 4.1
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:24:50 2000
Category of issue: Editorial
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
This first sentence should be under Checkpoint 4.2 and/or maybe
"font family and style" should be changed to
"font size." IJ Proposed: make suggested editorial fix
Key References: none
Issue 218 (Proposed Recommendation): Guideline 3 rationale mentions
color, but G3 checkpoints do not.
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:22:49 2000
Category of issue: Editorial
Type of issue: Guidelines
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Color is mentioned in the last sentence, first paragraph of the
opening text but not in "Ensure that the user..." or
in any other checkpoint under this guideline. Mention of it should
be removed and covered in Guideline 4 maybe
or a checkpoint or 2 should be added. What color is it referring to
anyway, text, background, ...? IJ Proposed:
Either make the suggested change, or argue that for background
images, color contrast may be problematic,
hence one reason turning off is a requirement.
Key References: none
Issue 217 (Proposed Recommendation): Checkpoint 2.1: Locational
information for equivalent alts
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:21:04 2000
Category of issue: Alternative content
Type of issue: Issue
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
beatnik.com provides technology that gives various audible tones
when you mouse over content objects. For
example, a button might be a bark, a form field be a sigh, etc. Is
this an equivalent alternative? If so I think the
equivalent alternatives description link needs to be enhanced so it
covers how to deal with locational information
presented in a narrow modality grouping (e.g. mouse and tonal). If
no, what covers this? Checkpoint 1.5? IJ
Proposed: Do not change dfn of equivalent alternative. Not sure
what "locational information" means...
Key References: none
Issue 216 (Proposed Recommendation): Checkpoint 1.5: Make status bar one
technique, not only
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:19:34 2000
Category of issue: Editorial
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
"...announce the event in text on the status bar as well..." Does
it have to be on the status bar? What if the UA's
"status bar" is a whirly hourglass or bar status indicator only
that purposely doesn't provide text for screen
space reasons? Perhaps the suggestion should be genericized to
provide visual feedback when a sound based
event occurs and the specific mention of the status bar be moved to
Techniques. IJ Proposed: Ensure that
wording states that info on status bar is one possible technique.
Key References: none
Issue 215 (Proposed Recommendation): Checkpoint 1.5: Fix button example
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:18:10 2000
Category of issue: Editorial
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
"...through a graphical button, ensure that the user interface also
provides access to the same functionality
through a control that includes a text equivalent..." The graphical
button itself should include a text equivalent
whenever possible, this doesn't say that. This is bad wording but
how about something like "...through a
graphical button, ensure that it includes a text equivalent (e.g.
tooltip) or that the user interface provides the
same functionality with a text equivalent elsewhere..." IJ
Proposed: Adopt suggestion
Key References: none
Issue 214 (Proposed Recommendation): Checkpoint 1.3: Change client-side
to all image maps
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:14:54 2000
Category of issue: Editorial
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Client-side is a specific solution, the rest of the example is a
little more general. I suggest moving the specific
mention of client-side to techniques and rewording to "...links in
a image map, and form..." because a better
solution than client-side could come along tomorrow. IJ Proposed: -
Make suggested change
Key References: none
Issue 213 (Proposed Recommendation): Checkpoint 1.2: Clarification in
note
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:12:58 2000
Category of issue: Editorial
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
"Note. This document addresses accessible user agent support for
some language features (e.g., tables for..."
Add Markup in front of language? Not sure what language(s) you mean
(e.g. HTML, XML, German, Java, ...). It
would be good to see "Follow operating system standards and
conventions and use open specifications"
mention platform specific UI styleguides because that is where
guidance on platform look and feel, "reserved"
accelerators, mnemonics, etc. are mentioned and discussed. It would
also be nice to see specific verbiage on
how important it is to look at, and factor into the design of the
UA, the guidance each platform's guidelines
provides (i.e. you don't want Alt+E doing one thing inside the UA
on platform A and it doing something else
outside the UA on platform B). IJ Proposed: Adopt suggestions - In
note, say "markup language" - To section
1.2 intro about OS standards, mention platform specific UI
styleguides.
Key References: none
Issue 212 (Proposed Recommendation): Guidelines do not cover new types
of user agents
Name: AC Review
Source URL: AC Review
Date: Sun Apr 9 08:10:07 2000
Category of issue: Scope of Guidelines
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
The Guidelines do not appear to address the full range of UAs that
are coming on the market. It may be possible
to infer how these new devices should work with web content but it
would be better if this could be spelt out as a
major part of the guidelines when they are first released.
Proposed: - No change - Add to FAQ - Ensure that
this is covered in new charter
Key References: none
Issue 211 (Proposed Recommendation): Do we need to say "alt equivs that
have been marked up as such" in 2.1
and 2.5?
Name: Ian Jacobs
Source URL: None
Date: Sun Apr 9 08:00:57 2000
Category of issue: Alternative content
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Some alt eq may be in prose. We should only require the UA to allow
to choose from those identifiable in markup.
Key References: none
Issue 210 (Proposed Recommendation): Add definition of author-specified
Name: Ian Jacobs
Source URL: None
Date: Sun Apr 9 07:57:48 2000
Category of issue: Definition
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Author-specified as used in the document means "in the document
source, there is markup that may be
recognized by the user agent for a particular purpose." Note:
Caution, since alt equivalents from the author may
be in prose, but these would not be recognized by the user agent as
such. We might want to distinguish
"author-supplied" from "author-specified".
Key References: none
Issue 209 (Proposed Recommendation): Checkpoint 4.12: Does this work for
XML?
Name: Ian Jacobs
Source URL: None
Date: Sun Apr 9 07:54:58 2000
Category of issue: User-control of Style
Type of issue: none specified
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
In WCAG 1.0, there's a bug about requiring that documents work
without style sheets since XML requires style
sheets for presentation. What does it mean to select only the
browser's default style sheet for an XML
application? Proposed: Add a note that in the case of XML, the
default styles will depend on the specification of
the application or the browser's chosen default behavior.
Key References: none
Issue 208 (Proposed Recommendation): Should users be required to have a
prompt or be allowed to configure for a
prompt when a form is submited
Name: Charles McCathieNevile
Source URL:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0480.html
Date: Tue Mar 28 13:28:02 2000
Category of issue: Forms
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments: none
Key References: none
Issue 207 (Proposed Recommendation): Interpretation checkpoint 2.1
Name: Phill Jenkins
Source URL:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0517.html
Date: Tue Mar 28 13:07:51 2000
Category of issue: Conformance
Type of issue: Checkpoints
Resolution summary: Not resolved
Resolution URL: Not resolved
First working draft: No reference
Comments:
Refer to summary:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0550.html
Key References: none
Received on Sunday, 9 April 2000 14:04:22 UTC