- From: Ian Jacobs <ij@w3.org>
- Date: Tue, 30 Nov 1999 17:41:26 -0500
- To: "earl.johnson" <Earl.Johnson@eng.sun.com>
- CC: w3c-wai-ua@w3.org
"earl.johnson" wrote:
>
> Must have been to much turkey this weekend... I re-read General Comments C.
> and D. and they didn't make sense so I've updated them below in hopes they'll
> be clearer. Sorry for any confusion my written confusion caused. Please toss
> out the 11/29 review and use this one.
Doh! I had started to respond with comments. I'll try to merge them
here.
All comments and replies are archived in w3c-wai-ua. For convenient
access to those issues and replies, the WG maintains a list at:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html
This list is linked from the WAI UA home page:
http://www.w3.org/WAI/UA/
Reference document for these comments:
http://www.w3.org/TR/1999/WD-WAI-USERAGENT-19991105/
> Thanks, Earl
Thank you!
- Ian
> ==========
>
> UA Guidelines review, rev. 1
>
> GENERAL COMMENTS
>
> A. While content display capabilities are important it is also
> important to ensure that the feature control portions of the UA UI
> are also accessible. The later means things like adjusting
> properties, getting to a menubar and it's entries, getting to and
> navigating secondary windows, choosing a location, etc. The
> guidelines explicitly address the content aspect but only implicitly
> address the features control aspect.
The Authoring Tool Guidelines includes references to accessibility
guidelines for different platforms. (Refer to [1], Guideline 7).
Perhaps the UAGL should adopt checkpoint 7.1:
7.1 Use all applicable operating system and accessibility standards and
conventions
(Priority 1 for standards and conventions that are
essential to accessibility, Priority 2 for those that
are important to accessibility, Priority 3 for those
that are beneficial to accessibility).
[1]
http://www.w3.org/TR/1999/PR-WAI-AUTOOLS-19991026/#gl-make-accessible
> With all the focus on content
> display there's a real risk that important aspecdts of the rest of
> the UA will be overlooked. It'd be nice to see the features aspect
> addressed or called out specifically in applicable guidelines. The
> guidelines this comment applies to are #2, #5, #7, #10 and perhaps
> #4. #4 provides a nice example for how this clearness can be
> achieved.
I'll add this to the issues list. Refer to
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#120
> B. Out of curiosity: Has someone sat down with the Web Content,
> Authoring Tools, and UA guidelines to verify that the UA guidelines
> cover all the UA dependencies covered in the Web Content and
> Authoring Tools guidelines?
Yes. Refer to, which is linked from the UAGL home page.
[2] http://www.w3.org/WAI/UA/wai-ua-wc-coordination.html
> It would be bad if the Web Content and
> Authoring Tools guidelines called for things the UA guidelines
> doesn't touch on.
I believe that ATAG depends on UAGL but UAGL doesn't depend on ATAG.
Yes. Refer to, which is linked from the UAGL home page.
[2] http://www.w3.org/WAI/UA/wai-ua-wc-coordination.html
> Adding the forgotten words...
>
> C. The guidelines and checkpoints in the document should stand alone so
> the reader has a pretty good idea of what they mean without having
> to rely on the Techniques document to explain what is meant.
Yes, I agree. Please indicate specific problems you found.
> Translating what was said originally into English...
>
> D. Sometimes the same basic checkpoint is found in more than one guideline.
> For example, checkpoints 1.3 and 10.3 seem like they could just as
> easily be merged into a single checkpoint under guideline #1 or #10.
Some checkpoints are specializations of others, so 1.3 is a special case
of 1.1 (this is noted in the text).
Checkpoint 1.3 is about device-independent activation of active
elements.
Checkpoint 10.3 is about user control of keyboard, voice, and other
input configurations. I don't see how they would be merged.
> Taken as a whole, the checkpoints can be thought of as a long lists
> of requirements which, from a development perspective, can be
> overwhelming.
Ok.
> While the checkpoints themselves say nothing about the
> engineering effort required, I think reducing their number if
> possible will make the accessibility effort seem like a less
> daunting one to the developer. So the suggestion is look for
> opportunities to remove checkpoints whose removal won't effect the
> guideline's completeness. My review contains a couple candidates for
> consideration.
Ok.
ONE GENERAL COMMENT ON YOUR COMMENTS:
You apparently have an entirely different model for organizing
the checkpoints in mind. It would be useful to me if you
were to repropose each Guideline based on the model you have
in mind. In short, how would your table of contents for the
Guidelines look read?
> SPECIFIC COMMENTS
>
> Section 1.5
>
> A. It's probably beyond the scope of this document and to early but it
> would be nice if a statement could be made about 508 and what
> minimum priority level is needed to enable compliance. Since access
> novices will (hopefully) be using this guideline when they design or
> redesign their UA, it might be good to add in another short section
> that gives highlights of or makes general statements about 508, the
> ADA, and the Telecom Act.
This is out of scope. The information you would like should appear in
a FAQ about the Guidelines, stating precisely that these Guidelines
are *not* law and explaining how they might be referenced. Refer to
issue 7 of the WCAG Fact Sheet [3] that was published when WCAG became a
Recommendation in May 1999:
<QUOTE>
11. Will these guidelines become a requirement? Are there legal
consequences
for not making accessible pages?
</QUOTE>
We could certainly make similar clarifications in a UAGL Fact sheet.
[3] http://www.w3.org/1999/05/WCAG-REC-fact.html#required
> Section 2 - UA Guidelines
>
> Guideline #1
>
> Checkpoint 1.1 - The second sentence should be removed because it feels
> like a design decision. It's a good point though so move it to the note
> or Techniques document.
The second sentence:
<QUOTE>
User agents are not required to reimplement low-level
functionalities (e.g., for character input or pointer motion)
that are inherently bound to a particular API and most
naturally accomplished with that API.
</QUOTE>
Has been included to address the concern expressed by some that
people might think checkpoint 1.1 means that users have to be
able to enter text with the mouse. If we move the sentence to
an informative note or the techniques document, the "requirement"
is lost. So it has been included directly in the checkpoint as
a clarification. If it's not clarifying anything, we may need
to change the wording.
> Guideline #2
>
> A. In the description paragraphs, are there formats from other areas that
> should be called out? SMIL is mentioned, is there anything from TV
> or other areas? I'm just wondering because th UA enables all sorts
> of technology convergence.
SMIL and HTML are listed as examples, and while I wouldn't want the
rationale section to grow too much, nothing prevents us from including
references to other technologies. It would be even more appropriate
to do so in the Techniques Document, but we have not had the resources
to address more than SMIL, CSS, and HTML for now. SVG and XML should
be included soon.
We are always welcoming text for the Techniques document, so if you
have proposals, don't hesitate to send them.
> Checkpoint 2.3 - I think of speech recognition when I see the term
> natural language. Is that what is meant here? If no, perhaps a better
> description can be provided so the reader doesn't need to leave the
> guidelines to verify what natural language means in the checkpoint.
The term "natural language" is defined in the glossary of the
Guidelines,
so technically speaking you don't have to "leave the guidelines" to
find that information.(There could be more links to the term from
the checkpoints; I'll add them.) Or do you mean that you don't even want
to have to consult the glossary?
Natural language is not limited to speech synthesis or voice input.
The term is meant to refer to human languages that are spoken,
written, or signed.
One way to render content according to natural language markup is
to use an appropriate font family. Another is to render as speech
using the appropriate speech dictionary.
> Checkpoint 2.7 - What if the object isn't video or audio? Is this
> checkpoint just for timed media or does it cover things like graphics
> or interactive objects that say nothing about themselves?
The checkpoint reads: "When no text equivalent has been supplied,
indicate what type of object is present."
This applies to any object for which an alternative equivalent
has not been provided.
> Checkpoint 2.9 - Natural language again. The Techniques document
> suggests this applies to the language that content gets displayed as or
> was written in. Given the speech recognition conotations mentioned in
> 2.3 do you think something besides natural language might be a better
> descriptor?
Again, I don't think this is limited to speech recognition. I hope
the glossary definition will suffice, but if you think further
clarification
is necessary, please let us know.
> Guideline #3
>
> A. A number of the checkpoints mention rendering. Should they be under
> Guideline #10 since it's sub-guideline calls out rendering or should
> rendering be moved from #10 to this guideline?
Meta-comment: It is true that some checkpoints might appear logically
in more than one location. We've tried to group tightly related
checkpoints
even though one or more might appear in other Guidelines and still make
sense.
Also, another reviewer has asked that the Guidelines and checkpoints
be more clearly divided along the lines of "Accessible content"
and "Accessible User Interface". [This comment was made to me,
by Phill Jenkins at an Authoring Tool Guidelines meeting
in Cambridge a couple of months ago.]
While the WG has already chosen this order for the Guidelines
(refer to Issue 59 [4]), the Working Group might consider further
cleanup.
[4] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#59
> Guideline #4
>
> A. Mentioning speech rate and pitch suggests to me the UA is the one
> providing the audio service.
> 1. Does this aspect of the guideline still hold true if the platform
> the UA is running on provides the service?
If the UA makes use of services provided by the operating system, that's
great!
> 2. Isn't it the audio service that should provide the control?
If the audio services is not "native" to the User Agent, then yes.
> 3. Does this mean the UA will need to provide a controller UI for
> all the audio services the user might have (e.g. different TTS
> devices)?
I'm afraid I don't understand the question.
> Checkpoints for the UI - a major design access problem we run across is
> windows that don't give an object input focus when they're made
> activate. I'm not sure if it should be here or under guideline #7, #8,
> or #9 but a checkpoint should say that a component needs to be assigned
> input focus for the content -and- feature control portions of the UA
> UI. This goes back to my general comment saying the feature control
> aspect of the UA UI needs to be explicitly covered.
I'll add this to the issues list. Refer to issue 122
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#122
> Guideline #5
>
> A. From the Authoring Tools Guidelines: "Guideline 7. Ensure that the
> authoring tool is accessible to authors with disabilities." The
> first descriptive paragraph for it states: "The authoring tool is a
> software program with standard user interface elements and as such
> must be designed according to relevant user interface accessibility
> guidelines."
>
> 1. While this excerpt doesn't yet specifically cover custom
> components it does basically say use the platform's UI toolkit
> when buuilding the authoring tool. I don't see the same clarity
> in this document. It's important that this document say something
> similar to: a) use the platform's standard UI components whenever
> possible and ensure that custom components provide equivalent
> accessibility information as standard UI components in the same
> programmatic way or b) ensure UI components not based on a
> platform's standard UI toolkit provide information and events
> equivalent to that found in currently available accessibility
> APIs (i.e. JAAPI and MSAA). My recommendation is this be a new
> checkpoint(s).
Added to the issues list as a proposed checkpoint. Refer to issue 123.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#123
> 2. Is this a guideline #4 point instead since it talks about the UI?
Guideline #4 isn't about the user interface in general; it's about
control of the user interface. Your suggested checkpoint would be
better under #5.
> B. As noted in the Techniques document Java Accessibility API and MSAA
> are public APIs. They enable the designer to easily make the feature
> control aspects of the UA's UI accessible and can be extended to
> cover many accessibility aspects of the content display. For
> example, JAAPI directly supports not only buttons and comboboxes but
> editable text also. But unlike DOM, SMIL, and other W3C specs they
> aren't mentioned in the main guidelines. Since they are relevant,
> why aren't the JAAPI and MSAA standards specifically mentioned as
> examples in this document also?
My personal take is: the guidelines should remain vendor/platform
neutral where possible. MSAA and JAAPI are implementations of the
checkpoints and as such appear in the Techniques document. DOM is
required explicitly, so is mentioned in the Guidelines. It is true
that HTML, SMIL, and other markup languages are not required in
the Guidelines document; they are examples only. There are checkpoints
for style sheets explicitly, so CSS and XSL could appear in the
Guidelines.
This merits some discussion. Refer to issue 124
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#124
> Checkpoint 5.1 - What API(s) is it refering to?
I agree that 5.1 needs clarification. Refer to Issue 125
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#125
> Checkpoint 5.4 - Should this be moved to guideline #8 since it has to
> do with orienting the user?
It also has to do with making selection and focus information
available to ATs. This is one that could appear in several places.
> Checkpoint 5.5 - How about rewording it to something like "Provide
> programmatic support that enables access to notification of changes..."
Current text: "Provide programmatic notification of changes
to content and and user interface controls (including selection and
focus)."
> This checkpoint appears to be aimed at situations where an assistive
> technology (AT) is utilized. For performance reasons I think the AT (or
> other UA talking to, the prime UA for that matter) should ask for the
> notification first before the UA starts providing it. The important
> point is to provide programmatic facilities in the UA so an AT or other
> technology has a clear place to go in the UA to let it know that they
> want notification of various events.
> 1. Since it's change oriented shouldn't this one be in guideline #9
> instead?
Added to issues list. Refer to issue 126
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#126
> Checkpoint 5.6 - This feels like a guideline #6 checkpoint because it's
> aimed at content.
Others have felt that 5.6 (on the DOM) should belong in G6 because
it's a W3C specification. Do others feel strongly about moving this?
> Checkpoint 5.7 -
Current text: "5.7 Provide programmatic exchange of
information in a timely manner."
> What does this mean from a UA perspective when things
> beyond it's control (e.g. the network) impact the performance? How does
> a developer know what this means as it applies to the UA? How will they
> know when they've successfully achieved this checkpoint? This
> checkpoint should be reworded or a better example cited so what is
> meant is clearer or the checkpoint should be removed.
Added to issues list. Refer to issue 127
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#127
> 1. General related document comment: the guidelines contain both
> specific and general guidelines all mixed together.
Do you mean general checkpoints or guidelines? Assuming you mean
checkpoints, the answer is: yes, there is a mix. First of all,
I don't know what it would mean (or how one would know) that all
the checkpoints have the same level of precision/generality.
Some of the generality has been included to allow for flexibility.
Some of the precision has been included to address particular needs.
> The Techniques document provides clarity on some of the general ones
> but not all.
> a. How will the developer know when they have successfully met
> those guidelines like the above?
There is no absolute measure. I think the standard should be
something like "a reasonable person, shown evidence, would
agree that the checkpoint has been met." The issue of "who
determines conformance" is one that is being addressed in the
WAI Coordination Group.
> b. What meaning does the Conformance seal of approval being
> designed have in situations like this where the determination
> of successful achievement depends so heavily on how well the
> developer thinks they've done?
It's not a seal of approval from W3C; it's an icon that represents
someone's
belief that a UA does or doesn't meet the requirements of the document.
I think the analogy is quite strong with case law: much is left open to
(and relies on) interpretation, review, and communication.
> Guideline #6
>
> A. Guidelines #5 & #6 without the checkpoints say the same thing to me.
Current text:
Guideline 5. Observe operating system conventions and standard
interfaces
Guideline 6. Implement open specifications and their accessibility
features
> But as I read the descriptions and checkpoints associated with each
> guideline #5 seems to be oriented towards the feature control aspect
> of the UA UI and #6 seems to be content display oriented.
Guideline 5 contains some information about content and some
information about UI:
Content: 5.6
UI: 5.2, 5.3, 5.4, 5.8
Both: 5.1, 5.5, 5.7
> 1. The wording of the 2 guidelines should be worked on so it's clear
> what they cover without the need of looking at the checkpoints to
> ascertain what they're covering.
Please suggest wording that would clarify the distinction.
>
> 2. If my impressions of #5 & #6 are right then #6 should only contain
> content oriented checkpoints and #5 should only contain feature
> control oriented checkpoints.
We could move checkpoints around to match that expectation:
1) Move checkpoint 5.6 (DOM) to G6.
2) Move checkpoint 5.5 (promgrammatic notification) to G9 on
notification
(will that be consistent with other checkpoints in G9? to be
verified...)
3) Checkpoint 5.1 needs clarification anyway.
4) Checkpoint 5.7 (timely notification) refers to "information", which
may be about content or controls. That could stay in G5 and, having
moved 5.6 to G6, we could refer to it from the DOM checkpoint.
That would leave all G5 checkpoints about the UI.
Thoughts?
> Guideline #7
>
> A. Comments on guideline wording and descriptive paragraphs
>
> 1. Regarding the sub-guideline: "Provide navigation mechanisms that
> meet the needs of different users: serial navigation for context,
> direct navigation for speed, search functions, structured
> navigation, etc."
> a. This starts off talking about the user but after the : symbol
> it talks about techniques in a way that doesn't connect it
> to the user. What does serial navigation for context and
> direct navigation for speed mean?
Proposed rewrite:
"Provide a variety of navigation mechanisms: direct access,
contextual access, searches, structured navigation, etc.
Users may find all of these mechanisms useful in different
browsing situations."
>
> b. I think everything after the : should be removed (especially
> since they're better covered in the descriptive paragraphs)
> or tied better to the user or reworded.
Try above rewrite.
> 2. The descriptive paragraphs seem to only talk about content display
> navigation. Navigating the feature control aspects of the UA's UI
> should also be specifically covered (see general comment A at the
> top). In case the guideline's Note was meant to do this - the
> Note doesn't make this point clearly.
No, the Note did not mean to cover this. You're right: besides view
navigation (7.1) and history navigation (7.2), the rest concerns
content.
This seems to be part of issue 120.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#120
> 3. The Note covers search, navigation, and location of input focus.
> The input focus shouldn't be mentioned here since it's covered in
> guideline #8 or the connection between input focus and
> search/navigation should be made clearer in the Note or
> descriptive paragraphs.
I'm not sure which Note you're talking about. Please clarify.
>
> Guideline #8
>
> A. Regarding the sub-guideline: "Provide information about resource
> structure, viewport structure, element summaries, etc. that will
> assist the user understand their browsing context."
> 1. The wording as I read it says it's aimed at the content author not
> UA. How about the following as a possible clarification
> alternative: "Enable user to get at content meta data to assist
> in understanding of browsing context (e.g. resource structure,
> viewport structure, element summaries, etc.)"
>
It's more than just giving access to author-supplied metadata. User
agents can actually generate useful information (such as a structured
view). Some of the checkpoints in this section refer explicitly to
"author-supplied" information where that is meant.
Perhaps we need an extra statement saying that information may
be author-supplied or generated (usually based on content, nonetheless)
by the user agent.
> 2. I don't know what is meant by "element summaries." It would be nice
> to see it touched on explicitly in the descriptive paragraphs or
> pointed to as a glossary term.
I propose dropping the term.
>
> 3. There should be more information on resource structure, viewport
> structure, and element summaries in the Techniques document as
> well as what other related structure etc. need to be exposed so
> that it's clearer to the developer what all they need to do.
Agreed. Suggestions are welcome!
> B. Keeping with general comment A, it should be stated that both the
> content display -and- feature control of (rest of) the UI need to
> clearly show focus.
> 1. For developers using a platform's UI toolkit, it's for them easy
> to think that the toolkit covers the focus issue however this
> isn't necessarily so, especially when custom components are
> utilized, and is something that the developer needs to explicitly
> verify.
Good point. Refer to issue 128
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#128
>
> Guideline #9
>
> Checkpoint 9.1 -
Current text: "Provide information about user agent-initiated
content and viewport changes directly to the user and through APIs."
> The "to the user and through APIs" part isn't clear.
> This isn't right either (because not all UAs will have a visual
> display) but "visually and programmatically" seems closer to the point
> it appears to me the checkpoint making.
It's not only visually. It can be through audio cues.
> 1. I'm confused about the user part because the user gets the
> information regardless of how the information is made available.
How does the user get the information regardless?
> 2. Specifically stating API sounds like the document is prescribing
> what is necessary to successfully acheive this checkpoint. As
> nice as it would be to do this, I don't think that's the
> intention of the document. Stating programmatic allows the
> developer to choose whether or not an API is the way tthey'll
> achieve this checkpoint.
What other programmatic means are there? Are we always talking
about APIs when we refer to communication with Assistive Technologies?
>
> Checkpoint 9.2 - I don't understand what this one is telling the
> developer to do. Adding a clarification example and/or working over the
> wording would be helpful.
The meaning: you move the selection or focus (e.g., by tabbing). If
it leaves the viewport and the viewport doesn't follow, a user
could become disoriented. Therefore, the viewport should follow
changes to the selection or focus.
However, saying "The viewport should follow changes to the selction
or focus" doesn't capture the key piece: the selection or focus
must be in the viewport after the change.
> Guideline #10
>
> A. How about making the descriptive, one sentence paragraph the the
> sub-guideline?
I'm not sure what this means.
> i.e. Replace "Allow users... the software." with "Web
> users..."
We don't refer to "users" as "Web users" in other places. In face, they
are "user agent users".
> 1. The mention of rendering, mouse, keyboard, the user interface in
> the guideline makes this guideline feel redundant to others
> already covered under separate guidelines.
The question is: Is configuration a sufficiently important topic
to merit a Guideline? Or should the checkpoints in question go
elsewhere?
Where, specifically, do you feel there are redundancies?
> B. General guideline comment: What exactly does input configuration mean?
> Perhaps this should be defined in the guideline's descriptive
> paragraph so developers are better able to translate it's meaning
> into the design of their UA.
There is a definition of "configure" in the Glossary. Perhaps this
should be moved to the descriptive text? The only problem is that
it is referenced from other Guidelines, so it was more consistent
to put it in the glossary.
> Checkpoint 10.3
Current text: "Allow the user to change and control the input
configuration. Users should be able to activate a
functionality with a single-stroke (e.g., single-key, single voice
command, etc.)."
> - I have a problem with this checkpoint because it
> really covers 2 things - what the UA should provide and what it should
> enable - but it doesn't present it that way. Single-key capabilities,
> for example, are directly achievable by a UA however single voice
> command is only possible if the UA provides it's own speech recognition
> engine that the user can configure.
> Staying with the speech recognition
> example, it may very well be a service provided by the platform which
> the UA knows nothing about (and shouldn't have to). This needs to be
> made clearer in the checkpoint as does what the developer needs to do
> to meet it (they can do single-key but they can only be expected to
> provide programmatic support that lets any input device control it).
Added as issue 129
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#129
> 1. What is the difference between this one and checkpoint 1.3?
10.3 is about configuration
1.3 is about activation/device-independence
A UA could satisfy 1.3 by allowing tabbing navigation (and navigation
by other devices) and never allow the user to configure the user agent.
> 2. If the plan is still to keep this checkpoint basically as it
> stands then how about:
> a. Move the second sentence should be moved into the
> checkpoint's descriptive paragraph because the main point is
> the change and control part.
There has already been a proposal from Eric Hansen to break
out the "single stroke" part into another checkpoint. However,
that proposal was dropped since it was based on a misunderstanding
(refer to minutes of last week's teleconf [5]). From the minutes:
<QUOTE>
We didn't mean that configuration had to be single stroke but rather
that
one be able to activate important functionalities with a preferred
keystroke.
</QUOTE>
Since your proposal is based on a different observation, it
will be discussed as part of issue 129.
[5] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0426.html
>
> b. Reword the checkpoint to something like "Allow the user to
> change and control how they interact with the user agent."
Ok.
> Checkpoint 10.4 -
Current text: "Use operating system conventions to indicate the input
configuration."
> What's this checkpoint saying? It's descriptive
> paragraph doesn't add enough clariuty for me. The example is mnemonics
> oriented but what should happen if, for example, speech input is used?
The checkpoint says use OS conventions. What are the conventions
for speech input? If there aren't any, then the UA doesn't have to
do anything (it would seem).
> Confounding this, input configuration suggests to me the method the
> user employs to do input but the example at least is more guideline #8
> or #9 oriented.
This was a choice to keep mnemonics (which orient) nearer to
configuration.
> Checkpoint 10.5 - How about rewording to something like "Avoid default
> input configurations that conflict with operating system navigation,
> control, and access conventions."
> 1. The access addition pertains to things like using 5 taps of the
> shift key to do something other than invoke StickyKeys.
>
> 2. The Techniques document should include a mention of the StickyKey,
> etc. keyboard invocation key sequences also since most desktop
> platforms provide them these days.
>
> Checkpoint 10.8 - Does this mean reconfigure where components in the
> content display and feature control parts of the UA are?
> 1. This highlights the general difficulty I have with this
> document - it's not clear when it's talking about the content
> part and when it's talking about the rest of the UI part. The
> Techniques document does happen to add partial clarity (it's the
> feature control part) in this case but the guidelines be clear so
> they shouldn't have to. Additionally, it's not clear if this
> means the user should be able to control the actual component
> layout of the UA.
Received on Tuesday, 30 November 1999 17:42:05 UTC