- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 25 Apr 2001 14:55:02 -0400
- To: jax@opera.no
- CC: w3c-wai-ua@w3.org, "Håkon" <howcome@opera.no>
Jonny,
First of all, thank you for your thorough review of the document.
I am particularly pleased that you provided implementation
details, as that will help us significantly as we advance to
Candidate Recommendation.
My comments below are preceded by "IJ:" I've snipped some
of your original text (where you didn't ask any questions).
Thank you,
- Ian
> Jonny Axelsson (jax@opera.no) wrote:
> This is a response to the UAAG 1.0 WD. In spirit with that the
> best way to test a specification is to try to implement it, this
> is an attempt to make a well-formed conformance claim. The
> exception is that we don't claim any conformance level (this is
> after all a drill).
>
> As a consequence this document is mainly about an Opera claim,
> but implicitly it is about UAAG and I hope this approach will be
> useful. There are also several comments directly related to the
> Guidelines themselves.
>
> This answer is primarily based on Opera 5.1 Win32. Opera is also
> available on a number of other OS-es, they are similar, but not
> identical.
>
> This is based on the working drafts of the middle of March, not
> the one of April 9th. There might be some discrepancies.
> ----- test run below -----
>
> Conformance claim
>
> Date: 2001-04-01
> User Agent Accessibility Guidelines 1.0
> Conformance level: (just a rehearsal)
> Subject: Opera 5.10 for 32bit Windows without any
> plugins or OS additions
>
> Opera 5.10/Win32 has no built-in support for video, audio or
> speech, neither has it the speech modality (note: Speech is
> missing from 3.1, the Input Modality Labels subsection).
IJ: We use the term "voice" for input and "speech" for output.
So in section 3.4 of the 9 April draft , "Voice" is one of the
input modality labels, while Speech is one of the content labels
in section 3.3.
> 1.1 Question: what is "fully operate" [1][conformant?]
>
> It is described in further detail below. The question remains,
> should all commands be available in all modalities? Also if it is
> not a "core function"? Opera has a great number of assistive
> functions, the vast majority of which are multimodal. Question:
> if a fully comformant UA adds a new function that is nonmodal, is
> it as comformant as before, less conformant or non-conformant?
IJ: Please let me know if I have understood correctly: are you
asking, for example, whether "fully operate" includes "operation
of the menus" or just "operation of the (core) functionalities
that are made available through the menus"? I think this is an
interesting question. I am not sure that it is critical to be
able to open menus and press on buttons, while it is critical to
be able to operate the functionalities associated with them. The
same point can be made about operation through an API: it's the
functionalities that are critical, not manipulation of the
interface mechanisms that provide access to them.
On the other hand, I think that in general, access will be
provided via the user interface elements themselves. Many user
agents will provide access to all functionalities by letting
users navigate menus in the (graphical) user interface. And I
think that user interface controls will also serve as the
interface to assistive technologies.
In the past, we tried to distinguish "core" functionalities from
"other" functionalities. For instance, at first, we didn't want
to require the user agent to implement character input through
the mouse. Our language for making the distinction became too
complicated and confusing, so we gave it up in favor of the
"fully operable" formulation.
In general, we take the following approach: "As long as the UA
provides service "X" one accessible manner, it can provide that
service in any number of inaccessible ways as well." So, for
instance, there can be N versions of inaccessible documentation
as long as one conforms to WCAG per checkpoint 12.1. And there
can be any number of non-text messages in the user interface as
long as there is at least one version of each message that is
text (per checkpoint 1.3).
--------
Proposal
--------
In the case of 1.1, we could probably say something like this
in a Note:
"The user agent is not required to make all user interface
controls keyboard operable. To satisfy this checkpoint, each
functionality offered by the user agent must be available
through at least one keyboard operable mechanism."
Please let me know if this is consistent with what you were
thinking.
[snip]
> 2.1 Alternative content for object [1][conformant, a bug]
>
> We do this for IMG, FRAMES, SCRIPT and OBJECT (not yet the
> standby attribute if this is an issue).
IJ: Wow, I had forgotten about the "standby" attribute. It's not
a required attribute in HTML 4.01.
> We have an issue with
> APPLET and alternative text. This is a bug and will be fixed.
> 2.2 Text source [1][conformant]
>
> We do show source view. It is unclear what other XML/HTML views
> apart from source view is referred to. The most natural way to do
> so would be through CSS.
IJ: I'm not sure what you mean by "what other views are referred
to". This checkpoint only refers to a (single) text source view.
> 2.3 Conditional content [1][conformant??]
>
> This paragraph is hard to understand (that it is priority 1
> doesn't help). I think Opera conforms, but we have bugs in our
> HTML implementation documented in
> <http://opera.com/opera5/specs.html>. They shouldn't adversely
> affect accessibility.
IJ: Ok, I will try to clarify the intention.
> Graphics: the G command to switch graphics off will display the
> alternative text. The display of the title attribute is user
> configurable.
IJ: This mechanism sounds like it would satisfy checkpoint 2.9
(at least in part, for "alt" text).
> Other attributes (longdesc, cite etc): This isn't on the W3C
> track, but Opera implements an extension to CSS to link to from
> or replace an element based on the URI (CSS Hypertext), a cleaned
> up version of this is proposed as [CLink]. This is great not only
> because of the flexibility and accessibility it offers, but also
> being CSS, it is user overridable. Opera manages an ordered list
> of HTTP languages.
>
> 2.4 Infinite timed input [1][conformant]
>
> We don't have any timed controls yet, but we may have and this
> will be on our mind. Question: would one hour be a close enough
> approximation of "infinite"?
IJ: I don't think so. It seems pretty reasonable that an hour
would suffice, but that doesn't mean infinite. We could try to
say "at least an hour", but why not 30 minutes? We chose not to
have to draw the line, so we said infinite. Is there a technical
reason why you would choose an hour?
[snip]
> 2.10 Unsupported natural languages [3][conformant?]
>
> This checkpoint could be clearer. We do server initiated language
> request (on the HTTP level we can say that we prefer a Norwegian
> version for an English one, but it is the server which ultimately
> decides what version we get). Content can be CSS styled using the
> lang attribute. We don't yet support Unicode, but we would give
> supporting it higher priority than giving symbol for character
> set not supported.
IJ: Ok, I will work on clarifying this. Language negotiation is
not intended to be part of this checkpoint (to my
understanding). The checkpoint refers to content (hence, the DOM
tree that the UA has already constructed). If the content
contains some information that the UA cannot render in an
intelligible manner, then we ask that it not render the content
at all.
> 3.1 Configure no background image [1][conformant?]
>
> *{background-image: none !important}, also a separate option. I
> am confused by "option to alert the user".
IJ: I think that the reasoning is as follows:
It's a P1 requirement to not load background images
automatically, which is more than a requirement just to be
able to turn them off. If the requirement were just to be able
to turn them off, then the user could have them on all the time
and turn them off when necessary. In this case, the alert
requirement could be a P3 requirement.
However, since the P1 requirement established by the WG is to not
render them automatically (on load, for instance), this means
that the user is likely to have this configuration on all the
time. In which case, the alert requirement is just as important.
It lets the user know that there's a background image (that might
be important) and the user can choose to manually reload.
> 3.2 Configure not to render [1][conformant]
>
> We can turn off both multimedia and plugins separately. We have a
> particular option for animations in Prefs > documents (show
> image, but not the animation). Graphics set not to render can be
> rendered individually using contextual menus. I don't think we
> can set individual images to animate if the rule is not to
> animate. Is there a need?
IJ: The WG decided there was a need to be able to turn
images/animations/video back on one by one: some users with
cognitive disabilities may not be able to process an excess of
visual information, and therefore need to be able to control how
much imagery is present on the screen at any given moment.
Having said this, please note that we restrict this checkpoint
for visual information to video and animated images, which are
intended to be "things in a box". However, SVG may be used to
create animations and they may not necessarily be in a box.
--------
Proposal
--------
Clarify in 3.2 that for video and animations, the user agent is
only required to satisfy the requirements of the checkpoint for
video and animations with a "fixed geometry". By fixed geometry,
I mean that once rendered in a particular region, the region
doesn't change except perhaps on user request, or by scripts,
etc. This would address concerns that some animations may take
over larger parts of the screen and therefore the placeholder
requirement doesn't make as much sense.
> 3.3 Nonblinking blinking text [1][conformant]
>
> The Opera interface doesn't use animation or blinking. The only
> way to get blinking text is by specifying it with the CSS
> property text- decoration:blink, which can just as easily be
> overridden by the user if need be.
IJ: Just a note to the WG: I think we will need to define what we
mean by "blink". What rate of refresh constitutes blinking?
[snip]
> 3.5 Client-side refreshes [1][conformant]
>
> The user has full control on refreshes. They can be as specified
> by the author, never or at a time interval specified by the user.
>
> 3.6 Client-side redirects [2][?]
>
> What is meant by this?
IJ: I will clarify the checkpoint. In the HTML case, this is a
META refresh, where the target URI is most likely different
from the URI of the page that contains the META element.
The techniques for 3.5 are relevant for 3.6, and I intend to
copy them accordingly in 3.6.
[snip]
> 5.3 Viewport prompting [2][non-conformant]
>
> This we don't do. Dialogue boxes during navigation are usually
> annoying. We give user configurable options and possibilities to
> override them (it is possible to open a new link in a new window
> using both keyboard and context sensitive menus), but we don't
> ask "Do you really want to open this window?".
IJ: You are not required to prompt the user in order to satisfy
this checkpoint. That's one technique. You could also satisfy
the checkpoint by simply not opening additional viewports, and
letting the user select them from a list of unopened viewports.
[snip]
> 6.1. - 6.10 User Agent and DOM [div][non-conformant]
>
> I have serious issues with this section. As I read it, it would
> be an absolute requirement to fully implement the DOM to get even
> an A level conformance. No other W3C spec makes DOM a
> requirement.
IJ: Actually, there are other specs that require support for the
DOM. For instance the SVG specification says the following in
appendix B.1 [1]:
<BLOCKQUOTE>
The SVG DOM is builds upon and is compatible with the
Document Object Model (DOM) Level 2 Specification [DOM2].
In particular:
The SVG DOM requires complete support for the
DOM2 core [DOM2-CORE]
</BLOCKQUOTE>
[1] http://www.w3.org/TR/SVG/svgdom.html#SVGDOMOverview
It makes sense for W3C specifications to build upon one
another. UAAG 1.0 requires conformance to other W3C specs (or
other specs that support WCAG 1.0) at a P2 level in checkpoint
8.2
> Opera is about to implement DOM (W3C of course),
> other browsers may not. My suggestion is that this is made into a
> separate "mode" so that one UA can have excellent accessibility
> but no API and another can have no accessibility but can get one
> through its extensive API.
IJ: We considered different conformance models, one of which
allowed for "stand alone" conformance (refer to issue 89 [2]).
At our 6 October 1999 teleconference [3], we rejected the split
because it undermined interoperability with assistive
technologies. Our target conforming user agents are user agents
running on PC-type environments (refer to the discussion of
section 1.2 "Target user agents" in the 9 April draft).
We are not as concerned with user agents running on very small
mobile devices (although we do not exclude conformance by them in
principle). Future guidelines may be more tailored to memory and
other constraints on mobile devices, etc.
[2] http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#89
[3] http://www.w3.org/WAI/UA/1999/10/wai-ua-telecon-19991006
[snip]
> 8.1 - 8.2 Follow the standards [1][conformant]
>
> These two points are so broad as to be of little use. One area
> where we don't follow the de facto standards is accesskeys. As
> implemented by NS and IE we feel they are of limited usability,
> and we'd rather do better. We haven't done so yet, though.
IJ: The issue of "what if we can do better?" is one that has been
raised by other reviewers (including AOL and Tantek Çelik), and I
think the WG needs to come up with a solid model for balancing
requirements for interoperability (W3C's mission after all) and
allowing innovation and improvements over existing technologies.
[snip]
> 9.3 Move focus to element and not activate [1][conformant]
>
> Keyboard navigation by default doesn't activate elements that get
> the focus, subsequently hitting enter is necessary. For pointing
> devices a click is an element activation, but a mousedown or
> context menu activation is not.
IJ: I think the UAWG needs to clarify that what is intended here
is that moving focus to an enabled element does not even trigger
an "onfocus" event.
> 9.4 Activate event handlers using alternate devices
> [1][non-conformant]
>
> In our ECMA/Javascript implementation we have no way of
> activating OnKeyPress using a mouse or OnMouseClick using a
> keyboard, but it is a good idea. I'll see if it is
> implementable. Note: Techniques and Guidelines seems out of synch
> here, points 9.3 to 9.6. There may be lacking a second sentence
> for 9.4 in Techniques.
IJ: The Techniques document was updated for last call. I'm not
sure whether the bug you refer to still exists. (Do you mind
checking?)
[snip]
> 10.2 Non-color default highlighting [1][conformant]
>
> This point relates to *default* highlighting, otherwise some of
> this could be solved by user CSS.
IJ: Why does that change anything? The user agent could implement
this through a style sheet that represents the user agent default
styles.
> A little dependent on OS,
> selection is highlighted either by OS selection color marking of
> the selected area (pointing device) or by a border with inversed
> color (keyboard). Focus is dependent on OS, such as using a
> dashed or dotted line. Links are by default underlined if text,
> and color specific for graphics (as is the difference between
> visited and unvisited links). This is user configurable
> independently for visited and unvisited links (prefs > document >
> links). Opera doesn't recognize fee links.
IJ: I can see an issue forming here: what if the user agent uses
operating system values for default values for these entities
(selection, focus, links, etc.)?
--------
Proposal
--------
For checkpoints 7.2, 10.3, 10.7, if the user agent inherits
default settings from the operating environment, and if the user
can configure them at that level, then the user agent satisfies
the checkpoint. For 10.3, the user agent doesn't have to ensure
that the differ from one another if they are inherited (and
configurable) at the operating environment level. The user agent
documentation should explain to the user how to change the
defaults at the operating environment level.
For checkpoint 12.3, if the user agent inherits the default input
configuration from the operating environment, and if they are
documented for the operating environment, then the user agent
satisfies the checkpoint. The user agent documentation should
explain where to find out information about the default bindings
in the operating environment documentation.
[snip]
> 10.4 Outline view and label for content [2][conformant?]
>
> A complex checkpoint that maybe should be split up. We show the
> labels inherit in HTML with the exception that we don't render
> LEGEND and LABEL usefully yet (we display them though). More can
> be done with CSS (we can display attributes using the content
> property and before and after pseudo-classes). Outlining H1-H6 is
> different. We cannot in the general case know which text belongs
> to each headline (this may change with XHTML 2.0) and we have no
> built-in outliner function. It is possible to make a very basic
> outliner using CSS though.
IJ: I will see what I can do to clarify the checkpoint. Can you
explain specifically what was complex?
[snip]
> 10.6 Configuration of selection/focus highlighting
> [1][conformant?]
>
> Partial repeat of 10.2?
IJ: Not exactly. These are 10.2 and 10.3 in the 9 April draft.
In this draft, 10.3 is only about the default highlight values
and their interactions with related mechanisms. Checkpoint 10.2 is
about the selection/focus highlight mechanisms in general.
[snip]
> 10.8 Ensure that a selection/focus remain in viewport
> [2][conformant]
>
> We do this. However a selection will not be lost if scrolled out
> of viewport, not should it. Among other things this would make it
> impossible to select more than a screenful of data.
IJ: I agree. The checkpoint doesn't require that the selection be
*completely* in the viewport.
--------
Proposal
--------
- Clarify in 10.8 (the same number in the 9 April draft) that
the selection and focus only have to be partially in the
viewport.
- In the definitions of selection and focus, clarify that they
may be completely or partially within a viewport, or
completely outside of it.
[snip]
> 11.3 Override any binding [2][non-conformant?]
>
> If customizable keyboard shortcuts is what is meant here: we
> would like to, but won't just yet. As for zero modifier keys, we
> go a long way to do that, but since the entire application is
> controllable from the keyboard we are running out of keys. Also
> there are usability issues. Example: Opera uses the Q/A, W/S, E/D
> pairs for navigation. A and Shift+A (anchor), S and Shift+S
> (headline), E and Shift+E would be much more mnemonic (no shift
> down, shift up), but have so far desisted in order to reduce
> modifier keys.
--------
Proposal
--------
I think that we should clarify that the user agent can
satisfy this checkpoint by entering a "single-key mode";
I would hope that this mode can be activated by a single key.
This means that, for example, the required bindings might not be
single-key by default, but very easily, the user agent could
provide a single key mode and satisfy the pertinent requirements.
I don't believe that this is inconsistent with 11.4 today,
because the single-key binding requirements are not default
requirements.
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Wednesday, 25 April 2001 14:55:23 UTC