W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2000

Issues list updated for 10-11 April Face-to-face

From: Ian Jacobs <ij@w3.org>
Date: Sun, 09 Apr 2000 14:03:52 -0400
Message-ID: <38F0C608.5D4F0403@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:03 GMT