- From: Ian B. Jacobs <ian@w3.org>
- Date: Tue, 12 Oct 1999 20:19:47 -0400
- To: w3c-wai-ua@w3.org
User Agent Accessibility Guidelines Working Group
Face to Face at Microsoft
12 October 1999 (Second Day)
Jon Gunderson (JG, UIUC, Chair)
Ian Jacobs (IJ, W3C, Scribe)
Kitch Barnicle (KB, Trace)
Hans Riesebos (HR, ALVA)
Harvey Bingham (HB)
Mark Novak (MN, Trace)
David Poehlman (DP, BARB)
David Clark (DC, CAST)
Judy Brewer (JB, W3C)
Jim Thatcher (JT, IBM)
Rich Schwerdtfeger (RS, IBM)
Gregory Rosmaita (GR, VICUGNY)
Charles McCathieNevile (CMN, W3C)
Dick Brown (DB, Microsoft)
Mickey Quenzer (MQ, Productivity Works)
Peter Wong (PW, Microsoft)
Tim Lacy (TL, Microsoft)
Wilson Craig (WC, Henter-Joyce)
Agenda [1]
[1]
http://www.w3.org/WAI/UA/1999/10/wai-ua-f2f-199910.html#agenda
Reference document:
http://www.w3.org/WAI/UA/WAI-USERAGENT-19991005
1) Face-to-face: 9/10 or 13/14 December
To process last call.
Action Judy: Follow up on hosting possibilities.
Action JG: Ensure that this is discussed at next telecon.
Action IJ: Announce this meeting being organized on the UA
page and list.
2) Issue 94: Should G2 be dropped?
CMN: Current draft has a guideline and
checkpoints. I think this is too much. Keyboard access
gives you a lot of bang for your buck, but shouldn't be
emphasized as the end-all since it's not always the
best thing to do. Shouldn't have an entire Guideline.
You need to be able to work out functions without
having to move through them spatially.
JG: Mousekeys does not satisfy the checkpoint.
IJ: I think the spatial issue is distinct from the
keyboard API issue. Users will find direct and
contextual access to functionalities useful. This is
distinct from mouse/keyboard activation but also
spatial/memory.
/* Do we delete G2? */
IJ: I support deleting G2 but leaving in the
checkpoints in a more abstract form (capturing the
requirement but distinct from the input device).
JT: I cringe at this. The checkpoints are already
abstract.
DB: We stress the keyboard a lot. I'd rather see G2
left in.
RS: Having written the Java guidelines, I observe that
applications are mouse-centric. Still get comments
today on the effective section on the keyboard
interface. I think a section on the keyboard is
critical so that developers do this correctly.
JB: The keyboard needs to be singled out and talked
about, even if there's not a whole guideline.
Resolved: Ok to leave G2 as is for now.
2) Issue 97: Document outline view
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#97p
JT: The wording of checkpoint 9.3 is not good. Don't we
already have a 'navigate' by structural elements. Is
this a technique for 8.6?
DC: Both apply to techniques.
CMN: In AUGL, you need to be able to navigate according
to structure.
JT: Why is this not for dependent user agents? This is
a functionality that is nice, but the author should do
this. I can see keeping 9.3 as a priority 3. For HPR,
the view is navigable.
DB: I think 9.3 should be P3 or moved to the appendix.
It's an implementation of 8.6.
HR: I think 9.3 is for all user agents.
IJ: Which is more important - the view or the
navigation?
(Navigation).
Proposed: Delete 9.3 in favor of 8.6.
Proposed: Create a checkpoint from Note after 9.3 but
for navigation.
CMN: Actually, 8.7 does what I want.
DB: I think that the outline is one way to allow
navigation by structure.
MN: Caution: 9.3 is about orientation, 8.6 is about
navigation. Do you want to lose this?
DC: Viewing by structure is extremely different than
navigating by structure. The view is important to give
users a sense of the document.
GR: Personally, I don't need an outline view. But
it is probably valuable to be presented with the
structured view and not have to create it as you go.
DP: If you're navigating by structure, you don't know
where you're going to go. As a person with low vision,
I want to know where I am in a document (as I
navigate). I think we should keep 9.3 (P3?).
DC: Don't assume a purely serial perspective on the
content.
JT: Navigation and view are the same in the serial
case. Different in other cases.
DP: I may want to know more about the document without
moving the focus. It's important for low vision and
cognitive.
MQ: Proposed making 9.3 a P3.
GR: The navigable view should be synchronized with the
main view to be most useful.
IJ: I suggest that this is a technique for 9.6.
DC: I think 9.3 needs to be a P2.
HR: I have a problem splitting the navigation part and
the view part.
Resolved:
a) Leave 9.3 as is (no longer for dependent UAs).
b) Take note from 9.3 and make this a P3 checkpoint.
3) Issue 98: "appropriate"
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#98p
IJ: Yesterday we changed 7.2 to: "Implement W3C
specifications when they are appropriate for a task."
JT: I'm ok with this.
4) Issue 98: Priority of control of UI layout.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0234.html
Dropped. No change.
5) Issue 100: Priority of control of UI layout.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#100
IJ: I wanted to warn readers that for some checkpoints,
mere mortals cannot verify them by observing behavior
of the software.
DP: Should we list the checkpoints?
IJ: I think that's possible, but why?
IJ: Is it problematic that some of our requirements may
not be easily answerable?
JT: It's inherent in this business.
DP: I have no objection to adding the note. In lieu of
or in addition to, we could/should annotate the
checkpoints that are difficult to evaluate.
HB: I think that this won't be consistent across
technologies.
DC: I'm concerned that if that a feature is not easily
noticeable (either by effect or cause), why is it in
this document?
JT: The standard example is that AT must know the
nature of the object with the current focus. That's
provided through the standard API. There's no way to
observe that short of software.
IJ: I mention this because I think that this will come
back to "haunt" us. I wanted the WG to ack this somewhere.
Resolved: Add Ian's proposed note.
6) Issue 101: Wording of checkpoint on document change notification
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#101
"10.1 Provide information about content and viewport changes (to users and through programming interfaces). [Priority 1]:
DP: I propose to drop "and".
CMN: IE shows changes by changing highlight,
scrollbars, etc.
Resolved: No change.
7) Issue 102: Wording of checkpoint on document change notification
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#102
JG: I reviewed this list last night. We've already
dealt with some of them: language, speech playback,
control rates, current view/viewport definitions.
JT: I want to drop the list.
8) Issue 103: Wording of checkpoint on document change notification
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#103
Resolved: Adopt Ian's proposal.
8) Issue 104: Wording of checkpoint on document change notification
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#104
JT: I like the proposal. I recommend that this be used
with the other guidelines.
JB: Where would they make the checklist available? On
their site? On the W3C site? The idea of supplying the
checklist sounds good. We'll have to work out the
detail about where the claim would reside, etc.
HB: I'd prefer that submitted checklists are annotated
(to show interpretations made).
DC: Is there a problem if it's not self-evident that a
checkpoint doesn't apply?
JB: I don't like the detail of having to list all the
checkpoints. I think it may be difficult to come up
with clean "groupings" for user agent classes. But this
won't be the only one. It's hard to come up with stable
profiles. Other W3C WGs have tried to come up with
profiles and failed.
DB: Legal issues - providing detail about where you
comply may be used as evidence. I'd have to talk with
lawyers.
GR: Need boilerplate disclaimer if evaluations posted
on W3C site. Companies should get these evaluations.
JB: W3C would not put definitive reviews unless we
couldn't get the organization to do it. We would
document that there was not reply from the
organizations.
GR: In my reviews, I documented how using one
particular screen reader would change the conformance
situation.
Resolved:
1) Adopt Ian's proposal (software version/OS, date).
2) Action Ian: Propose how the checklist will be delivered.
9) Issue 105: ACCESSKEY implementation issues
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#105
JG: Issues:
a) What's the behavior of "accesskey"?
- Move focus?
- Move focus and activate?
b) Combination keys are platform-dependent
c) How do you know that an author has supplied access
keys?
d) How do you resolve conflicts between keys specified
by authors/system/UA/user/AT.
MQ: I don't think that accesskeys should focus +
activate.
JT: I wish that this had been done in HTML 4.0 correctly...
Given the disaster, I propose these resolutions:
a) Focus without activate
b) Use system conventions to indicate availability of
access keys.
c) Defer to the environment (not Web page)
in case of conflict.
MN: Please consult the CSS3 WD [1], [2] for information about
keyboard control. This WG should ensure that what we
discuss is consistent with those developments.
[1] http://www.w3.org/TR/1999/WD-css3-userint-19990916
[2] http://www.w3.org/TR/1999/WD-css3-userint-19990916#keyboard
JT: Note the problem in the definition of [2]:
"Key-equivalents are active in a document
only if an element inside the document has
the focus (this can include BODY)."
JT: This is not what we say in UAGL.
IJ: I think this is a mistake and they mean that
configs only apply when in a particular viewport.
JG: Summarizing - we need to ensure compatibility with
other W3C specs.
DP: I don't think pointing to HTML 4 or CSS3 is
sufficient. The way it's defined in HTML 4 is too vague
- it's broken. Not clear whether focus + activate or
just activate or just focus. I want to look in
particular at checkpoint 2.5 but also keep in mind
where accesskey should be stressed in the techniques or
other checkpoint notes.
DB: Authors should indicate what accesskeys they
provide.
GR: You can't use Alt-H and Alt-F accesskeys in IE 4/5
since they're overridden by IE.
TL: I think it's important to be platform and
browser-independent in resolving this issue. This WG
should not try to fix the problem (since out of scope).
Also, don't rely on HTML 4 or CSS 3 alone since they,
too, will pass.
CMN: I agree with TL. Accesskeys provide hints to the
UA. It's the responsibility of the UA to use that
information to construct a different user
interface. Thus, authors shouldn't have to always
document their access keys. In fact, the UA may remap
the access keys. The author has no guarantee about how
the UA will handle the accesskeys.
TL: I agree with CMN. If you can successfully remap the
author-supplied interface to the UI, you've solved a
lot of problems.
MQ: At Productivity Works, we do this. The user can
customize the keyboard configuration. The help files
are updated on the fly.
RS: We shouldn't specify accessibility requirements on
something this poorly defined.
DC: I think 2.4 to 2.8 should be P3.
CMN: I don't agree.
DB: Just because you can't configure the UA doesn't
mean you can't get at the UA.
DP: There are some tools that capture the
functionalities intended in 2.4 - 2.8.
Issue for 2.5: Implied here that author-supplied key
configs override UA configs. But it's not clear that
UAs do this consistently.
DC: I don't think there's any problem with the current
2.5.
HR: I think we need to ensure that the user have access
to all keys specified by the author (however that's
resolved - either what the author specified, how
they're remapped, etc.).
RS: If you're going to keep 2.5, keep statements like
"Can't override the default UA configuration or system
keyboard configs."
Action GR: Repropose 2.5 so that it's clear that there
should be a cascade order whereby the user has ultimate
control or can concede control to the tool.
Resolved:
Since HTML 4.0 doesn't specify focus + activate
behavior sufficiently, the WG won't try to fix.
Issue: Should 2.3 include author-specified key
bindings?
CMN: I think 2.3 already includes author-specified key
configs.
DB: I don't think this should be P1 for the UA.
JT: You can get at all active elements through serial
navigation. So you don't need to make direct access a
P1.
CMN (Summarizing/Proposing)
1) Serial access P1
2) Direct access P2
3) Documentation of direct access P2
DB: I think that documentation of defaults should be P1
but that documentation of author-specified configs
should be P3.
RS: Accesskey doesn't let you describe the functions.
So how does the UA document the access keys? Therefore
I agree with DB.
CMN: I think should be P2 to document keyboard configs.
JT: I think it's problematic to put P2 on something
poorly specified.
DC: I have a problem with how we're missing content
with UA functionalities.
Resolved: Copy 8.4 to new checkpoint, removing "just"
and making it a P1. (Leave 8.4 as P2).
MN: Note that in DOM2, all elements can take the focus.
CMN: Then our definition of active elements is broken.
Action MN: Propose a new definition of active element.
IJ: Is there a requirement for
"Direct access to active elements."
JT: No.
JG: This was decided a long time ago.
IJ: How much should author and UA configs be conflated
in documentation of current config?
CMN: Most important is to document "what works at the
moment?"
CMN/TL: Yes. The user doesn't need to know the
difference.
Proposed: Make checkpoint 2.3 for author-specified only.
Move to P3.
"2.3 Provide information to the user about
author-specified keyboard configurations."
HR: If this is done, move 2.3 to another guideline.
CMN: We're making the wrong split. There are two
things we need to document:
a) How can I get at something somehow? Documentation
of this is P1.
b) Other means for getting at the something. Documentation
of these techniques is less important. I think it should
be P2.
HR: I think that 2.3 should remain as is, for user
agent-supplied current configuration. Move the
author-supplied information somewhere else (lower
priority).
DB: Propose that documentation of author-specified
bindings be a separate checkpoint, P3.
DC: I think that display of P3 information as a P2 is
logically inconsistent.
JT: Yes.
CMN: I don't think it matters who supplies the
information. At the user end, what's important is how
it works. As to how it can be P2 in UAGL and P3 in
WCAG: providing direct access is like providing outline
views. These are strategies for making access
faster. Having the ability to do things more quickly
than serially is quite important. Why are UA-supplied
accesskeys more important than those that the author
considers important? These are important, not just
beneficial.
GR: I agree with CMN. I think that providing a list of
accesskeys should have been a P3 in WCAG.
DB: We're talking about an author-specified alternative
to getting at information they can get to in a standard
way. It's beneficial, but not more.
MQ: Making it P3 says to the author that their
accesskey was not important. It's frustrating if
users don't know that keyboard behavior changes.
JT: Documenting direct access is important. But the
implementations are so flaky, that it shouldn't be P2
today.
DP: I don't think that there needs to be matching
priorities between WCAG and UAGL. I think that current
keyboard config should be in a single checkpoint.
KB: I think ok to add "author-specified" to 2.3 and
make P3.
DC: Don't remap keys without the user's
knowledge. Notably if changes are to the default
configuration.
RS: Can we say something about the poor specification
of access keys?
DB: I think it's more important to talk about
reconfiguration of the user agent's configuration.
It's P1 to know what has changed in the UI if the
change means you can't get at UA functionalities.
Configuration should include on-the-fly documentation
of the changes.
Proposed: "2.3 Provide information to the user about
author-specified keyboard configurations. P3"
DP: There are some scenarios that aren't covered in the
current proposal.
Action CMN: Write a proposal to address this issue.
/* Wilson Craig arrives */
/* Lunch 12:50 */
/* Techniques mini-groups starting at 14:00 until 15:30 */
Techniques for Guidelines 1, 2, 3. (Rich Schwerdtfeger, Tim Lacy,
Gregory Rosmaita)
Techniques for Guidelines 4, 5, 6 (Ian, Hans, Mickey, Dick)
Issue: Why is 4.1 a Priority 1? If you use a text-only
browser, and the images slow download, this becomes an
accessibility issue.
Resolved: Make 4.1 a Pri 3.
Resolved: Add a note to 3.1 about ensuring that alt
content available when primary content turned off.
Proposed: Generalize 3.8 to apply to more than just
continuous tracks : all sources of alt content.
Action Ian: Propose on the list.
Resolved: Clarify that G4 is about author-supplied
resources.
Resolved: Drop 4.5 since covered by 3.8 (case of zero
tracks selected).
Resolved: Drop 4.9/4.10 since covered by new checkpoint
for choosing from among style sheets.
Issues surrounding techniques for turning on/off
content:
1) How is formatting affected?
2) How are active elements affected?
3) How is access to alt content affected?
4) Downloading: need access to geometry and embedded
alt content.
Start with assumption that alt info is available.
Not downloading:
1) Geometries of content.
2) Embedded alt content
3) timing information
Formatting:
1) Take up the preferred geometry?
2) Alt content exceeds the size of the preferred geometry?
3) Should you render inline or in some other view:
distinguished or integrated in content?
4) Need to be able to distinguish image links from
their longdescs.
5) Allow the user to say whether geometry should be
respected or dropped.
DB: I don't think we should be telling developers how
to do something in the UI. I think the techniques
should tell developers what issues may arise when they
do something.
HR: Do we need a particular checkpoint for
background sounds? There is one for background images,
why not one for sounds?
DB: Sounds are in one plane (you hear all sounds
together).
GR: I agree with HR. Some content is delivered with
real audio. If you're using synthesize, there may be
clashes with the device.
Proposed: Add a checkpoint to turn on/off background
sounds.
Action Ian: Propose on the list.
Background images:
- Hierarchy.
- CSS
- fg/bg color
Techniques for Guidelines 7, 8, 9.
(David Poelman, Wilson Craig, Judy Brewer)
7.1
*Implement all listed elements and attributes in:
JT: I have problems with the term "all".
CMN: So say "Refer to section so and so".
- "Accessibility features of HTML4"
- "Accessibility features of CSS2"
- "Accessibility features of SMIL"
*Also implement section Sec. 5, 6, 7 of current techniques document
7.2
*for marking up Web pages use HTML or XML
*for presentation use CSS
*for multimedia use SMIL
*for math use MathML
*for event model use DOM
8.1
*define a key stroke to rotate between available viewports
independent of
standard browser controls
[or]
*allow user access to selectable list of viewports
8.2
*write your code so "back" command takes you to the
previous point of regard.
8.3 *provide an independent table mode that allows the
user to navigate around a table w/ arrow keys
(IJ: May be deleted if we adopt table proposal.
If we keep in appendix, keep in appendix?)
8.4
*enable sequential navigation by tabbing
*enable direct nav by entering link text
*enable searching on active elements only based on form control
text,
associated labels, or form names
*create selectable lists of active links
8.5
*allow user to view a list of elements with associated alt text
*enable searching of alternative content through an
option in the search dialog box
8.6
*assign keystrokes to jump to selected types of
elements and then navigate those selectively
8.7
*allow user to set global navigation preferences
within the browser, plugin, multimedia player or
assistive technology
DB: What does this mean?
WC: If you're going to allow people to jump to elements
by type, they may want to jump by default to some
types, or to skip some types. E.g., read only headers.
9.1
*assign keystroke to query and announce status of
highlighted element
*allow structured selection.
9.2
*provide number of open viewports on the status bar
*assign keystroke to announce number of open viewports
*implement a windows menu.
9.3
*implement DOM in dependent assistive technologies
[and!]
*provide dialog boxes containing lists of structural elements with
user-configurable detail level
* Implement CSS and provide a structured view with
style sheets.
9.4
*provide information in fraction form on status line,
e.g. 7 of 9 links
*enable announcing of relative position of each element
as brought into focus
*use proportional scrollbar (AT will be able to access
the scrollbar information).
9.5
*implement W3C Recommendation [Not yet a
Recommendation] for Micropayments 1.0
IJ: Micropayments spec doesn't talk about rendering.
[and!]
*enable announcing of payment obligation incurred by
micropayment link activation with an option to remove
focus without commiting
9.6
*display information on status bar regarding link
context including visitation history, internal or
external link, targetted link, whether it activates an
executable file, language of target of link
[or!]
*allow this to be announced
*allow the user to receive information about the link
in context
9.7
*allow user to configure what types of information
about link context to present
9.8.
<<largely redundant w/ 9.1, condense and also add>>
*implement CSS2 mechanisms for link highlighted
9.9.
*implement object model of DOM2
*enable announcing table header elements where available
9.10
*implement object model of DOM2
*assign keystroke to announce the row and column dimensions of
selected table
9.11
*implement object model of DOM2
*enable announcing of information regarding title, value, grouping,
type,
status and position of specific focused elements
9.12
*use consistent strategies & methods for user
selection, control options, and navigation controls
*establish quality control and assurance processes for
consistency of access strategies across software
releases
Guidelines 10 - 12.
10.1 Provide information about content and viewport changes (to users and
through programming interfaces). [Priority 1] (Checkpoint 10.1 in
guidelines)[23]
Techniques are in section 3.6.8Scripts
* Render the changed content graphically.
* Highlight the current viewport.
* Make the viewport available programatically.
* Beep when a DOM change occurs.
* Make DOM methods fire a "change" event that can be trapped
(does DOM2 have this already?)
NB: JT is not comfortable that the notification is always so
important anyway
10.2 Ensure that when the selection or focus changes, it is in the
viewport after the change. [Priority 2] (Checkpoint 10.2 in
guidelines)[24]
Techniques are in section 3.4.2 Tracking selection and focus
* Do what the checkpoint says.
* Make sure that search windows do not place the new focus that
is the found object under a search popup.
* Only change selection/focus in the current veiwport.
* Move the viewport when the focus is changed to an object
outside the current viewport (e.g. search)
10.3 Allow the user to selectively turn on and off notification of common
types of content and viewport changes. [Priority 3] (Checkpoint 10.3 in
guidelines)[25]
Techniques are in section 3.6.8Scripts
* Allow the user to disable notification of changes to CSS
properties
* Allow the user to disable notification of images that are
changed
* Allow the user to specify an element for which notification
should be disabled (eg table, body, img, ...)
10.4 When loading a resource (e.g., document, video clip, audio clip,
etc.) indicate what portion of the resource has loaded and whether loading
has stalled. [Priority 3] (Checkpoint 10.4 in guidelines)[26]
Techniques are in section 3.6.1 Status information
* Use a status bar to give progress percentages (as text or
progress bar)
* Use the notification facilities required by 10.1 to inform that
loading has stalled
10.5 Indicate the relative position of the viewport in a resource (e.g.,
the percentage of the document that has been viewed, the percentage of an
audio clip that has been played, etc.). [Priority 3] (Checkpoint 10.5 in
guidelines)[27]
Techniques are in section 3.6.1 Status information
* Provide a scrollbar for the page.
* list as page X of Y.
* Use a variable pitch to indicate position.
* Keep the information numerically and generate the output on
user request. See new HTML work on Forms for further examples
(a slider is like a dial is like a menu of lots of options...)
* Provide standard markers for specific percentages through the
document (mileposts)
* Provide markers for positions relative to ... (a user selected
point, the bottom, the H1)
* Put a marker on the scrollbar, or a highlight at the bottom of
the page while scrolling (so you can see what was the bottom
before you started scrolling
10.6 Prompt the user to confirm any form submission triggered indirectly,
that is by any means other than the user activating an explicit form
submit control. [Priority 2] (Checkpoint 10.6 in guidelines)[28]
Techniques are in section 3.6.6 Form controls
* Put up a dialog indicating the form will be submitted if it is
done by an onChange, after a certain time, or for other
script-based submission.
* If the submit button is not the last control in the form, and
no controls after it have been focussed, put up a dialog
pointing this out/asking if the user has filled in the
information after the button.
* To be kind, allow these dialogs to be banished forever
* If a javascript submission is fired, allow the user to ask for
it to be intercepted and trigger the dialog mentioned above.
Guideline 11[29]:
11.1 Allow the user to configure the user agent in named profiles that may
be shared (by other users or software). [Priority 2] (Checkpoint 11.1 in
guidelines)[30]
Techniques are in section 3.8.1 User profiles
* Store preferences as a named file, and allow users to select
from different files
* Provide a default profile and a means to set a new default
profile
* Allow the user to save preferences as a new set of profiles
* Store preference information such as customised layouts, email
address, proxies, style preferences, and everything else.
11.2 Allow the user to configure the graphical arrangement of user
interface controls. [Priority 3] (Checkpoint 11.2 in guidelines)[31]
Techniques are in section 3.8.3 User interface
* Allow the user to choose large or small icons
* Allow the user to choose icons and/or text
* Allow the user to change the grouping of icons
* Allow the user to re-organise menus
* Allow the user to change the position of control bars, icons,
(etc (etc (etc etc)))
* Use a greater range of size than big/small icon sizing.
* Do not rely solely on drag-and-drop for reordering tool bar.
Guideline 12[32]:
12.1 Provide a version of the product documentation that conforms to the
Web Content Accessibility Guidelines. [Priority 1] (Checkpoint 12.1 in
guidelines)[33]
Techniques are in section 3.9.2 Accessible documentation
* Provide documentation in WCAG-compliant HTML
* Illustrate with images that include text alternatives (alt and
longdesc)
* Provide documentation as a gif. Also convert it into PDF and
then write it out in Word binary image format
DB: I think this checkpoint is too specific to HTML (since WCAG very
oriented towards HTML). I don't think that these guidelines should
dictate that help be in HTML.
CMN: A document does not have to be HTML to conform to WCAG.
DB: Old Windows Help was in many ways more accessible than current
HTML.
DB: I'll go back and look at WCAG. I think that there's an issue here.
Resolved: No change for now.
12.2 Ensure that all user agent functionalities that promote accessibility
are documented. [Priority 1] (Checkpoint 12.2 in guidelines)[34]
Techniques are in section 3.9 Documentation
* Document features included to comply with these guidelines
* Integrate keyboard and mouse access methods in documentation
* Highlight standard Operating system features (mousekeys, window
controls, hotkeys, etc) which can be used in the User Agent
12.3 Describe product features known to promote accessibility in a section
of the product documentation. [Priority 2] (Checkpoint 12.3 in
guidelines)[35]
Techniques are in section 3.9.1 Where to document accessibility
* Collect everything for 12.1 and 12.2 and put them in an
accessibility chapter
Received on Tuesday, 12 October 1999 20:18:10 UTC