- From: Jonny Axelsson <jax@opera.no>
- Date: Thu, 19 Apr 2001 02:56:18 +0200
- To: w3c-wai-ua@w3.org
- CC: Håkon <howcome@opera.no>
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 UUAG 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.
Jonny Axelsson
Documentation,
Opera Software
----- 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).
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?
Input/interaction devices available in Opera
(*) Through windows, menus and pointing device (not necessarily using a
mouse--this is written on a mouseless system). All keyboard commands
are available through the pointing device interface, not necessarily
as conveniently.
(*) Keyboard. It is possible to have practically full control of Opera only
using a keyboard, there are however a few commands not reachable this
way. The most useful browsing commands are directly available through
the keyboard, not through menu equivalents.
(*) Contextual menus and pointing device actions not using OS menus. This
is the poorest set, but should be more than sufficient for normal
browsing. There are a couple commands that are *only* available through
context menus (like validate HTML), this is a UI and WAI bug and should
be fixed. Not that in Opera the contextual menu is also available
through keyboard command (Ctrl+M). An exception is on EPOC, that doesn't
have a contextual menu.
We have no built-in system for voice input, and are dependent on third party
solutions for each OS (BeOS, EPOC, Linux, Mac, OS/2, Win16, Win32).
1.2 Interaction with active elements [1][conformant]
Yes. This we do (with the exception of native voice input), and it is to a
large extent configurable.
1.3 Text equivalents in the UI [1][conformant]
We don't use images or sounds for anything else than ancillary/illustrative
purposes (e.g. email filters may optionally have a sound added).
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). 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.
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
accessability.
Graphics: the G command to switch graphics off will display the alternative
text. The display of the title attribute is user configurable.
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
accessability 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"?
2.5 Text transcripts [1][conformant]
At this point in time we are not very aural (for good or bad). Plug-ins
might be, but we'll have no direct control of these.
2.6 Synchronization cues [1][conformant]
As with 2.5.
2.7 Repair text [2][conformant]
Opera generates repair text, The actual text string for IMG repair text when
none is given (IMAGE) is configurable in the string 20078 in <language>.lng.
2.8 No repair text [3][conformant]
When the img alt attribute is explicitly set to "", or an object is set to
have no content, Opera will not show any repair text.
2.9 Allow the user to configure... [3][conformant]
This kind of user configuration is something we are proud of. Graphics we do
by pressing "G" (or the button on top of every window), other content by
Preferences > Document. Displaying alternate content directly coded or
linked to in attributes can be done by standard CSS2 we fully support (the
content property) or Opera extensions (links) . To be turned on/off at the
press of a ctrl+G.
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.
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".
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?
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.
3.4 Not execute executables [1][conformant?]
It is possible to disable Java, Javascript and plug-ins individually. We
haven't implemented any option to alert the user that executable content has
not been executed.
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?
3.7 Configuring the rendering of image [2][conformant]
The G command in Opera. Each separate image can be handled by the context-
sensitive menu.
4.1 Size of rendered text [1][conformant]
(*) Zoom (20%-1000%), accessible both with pointing device and keyboard.
(*) Pref > Document > Minimum font size,
(*) Pref > Document > User fonts and colors,
(*) User CSS, can be overridden by User Mode (ctrl+G).
4.2 Override font [1][conformant]
Pref > Documents > User fonts and colors as well as User CSS.
4.3 Override foreground and background colors [1][conformant]
As with 4.2
4.4 - 4.10 (Multimedia, audio) [div][N/A]
Not applicable. Multimedia is done through external applications.
4.11 - 4.15 (Synthesized speech) [div][N/A]
As with 2.5, we're not very aural ourselves. We might be interested in
delivering parsed XML/ACSS to a third party, but we're not there yet.
4.16 Choose between author/user CSS [1][conformant]
This we do.
5.1 Change viewport [2][conformant]
This we do.
Comment: many of the examples uses the form myObject.method. While this is a
common way of implying an instance of an object, this probably should be
noted.
5.2 Viewport on top []2[conformant]
Apart from the possibilities given by the OS, new windows can be opened in
the background.
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?".
5.4 Form submission prompting [2][non-conformant]
We have no way today to halt scriptbased form submission exclusively (apart
from turning off scripting).
"Generate an explicit form submit button when the author has not provided
one." This we can't do. If an author has omitted a submit button it would be
by design, possibly bad design or possibly because the form is not meant to
be submitted anywhere.
5.5 Fee link prompting [2][N/A]
Opera doesn't recognize fee links.
5.6 Closing viewports [3][conformant?]
We have a few cases where Opera users are prompted when a Javascript might
do something the user might not want to do. Generally JS has control of what
it created and little else. We have decided not to implement a few JS
features, like the print command (where the author can specify that the user
should print the current document), if we implement it, it certainly will be
with a dialogue box.
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
comformance. No other W3C spec makes DOM a requirement. 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 accessability but no API and another can have no
accessability but can get one through its extensive API.
7.1 Follow OS UI conventions [1][conformant]
I am not aware of any real breaches.
7.2 Default input configurations don't interfere with OS conventions [1]
[conformant]
As with 7.1. We have mouse gestures that might theoretically interfer with
similar applications, but they are optional.
7.3 Follow OS UI conventions that benefit accessibility [2]
As with 7.1.
7.4 Follow OS UI conventions to indicate input configuration [2]
As with 7.1.
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.
9.1 (Keyboard) navigate between frames/viewports [1][conformant]
We do that. By pressing "3" you can navigate between frames in a window. By
pressing "1"/"2", you can navigate to previous/next window.
9.2 Navigate all active elements [1][conformant]
This we do for active as well as non-active elements. Keyboard navigation
includes Tab/Shift-Tab, A/Q, S/W D/E for next/previous form
control/link/headline/element respectively and ctrl+J for quick link
access. The arrow keys changes position in the layout, and
PgDown/PgUp/Home/End keys move the viewport. Pointing device navigation uses
the normal UI conventions.
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.
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.
9.5 Keeping point of regard [1][conformant?]
We do that for web as well as other windows. We have a bug with OperaShow
(F11) that loses point of regard, and that will be fixed.
9.6 Query element for explicitly declared event handlers [2][non-conformant]
Giving a list of all active eventhandlers for an element is something else
we might like to do.
9.7 Navigate only active elements [2][conformant]
This we do too.
9.8 Search [2][conformant]
Both move the viewport and continue search. We don't search source code, but
the associated source code viewers will.
9.9 Navigate among structural elements [2][conformant]
This we do.The keyboard navigation in 9.2 is efficient, especially combined
with moving the viewport. If the element is high in the viewport, the
element will be reach with only a few key clicks.
9.10 Configure important structural elements [3][non-conformant]
This we don't. The navigational elements aren't user configurable.
10.1 Table non-visual information [1][non-conformant?]
As a visual browser we have limited opportunities to do this. Even so, this
is a point where we could do much better, and this will soon be under
review.
10.2 Non-color default highlighting [1][conformant]
This point relates to *default* highlighting, otherwise somoe of this could
be solved by user CSS. A little dependent on OS, selection is highlighted
either by OS selection colour marking of the selected area (pointing device)
or by a border with inversed colour (keyboard). Focus is dependent on OS,
such as using a dashed or dotted line. Links are by default underlined if
text, and colour 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.
10.3 User-configurable link highlighting [2][conformant]
This we do (as illustrated for Opera 3.60). Prefs > Document and user CSS.
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
pseudoclasses). 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.
10.5 Ancillary link information [3][conformant?]
We display what we know about a link. One possible caveat though, I have to
check whether a TITLE pop-up text will also appear in the status bar instead
of the URL, that would be a bug. Visited links are marked differently. Other
information, like resource language, could be displayed using CSS.
10.6 Configuration of selection/focus highlighting [1][conformant?]
Partial repeat of 10.2? Apart from Prefs > Document options, this can be
done through User CSS. We haven't implemented the CSS2 property outline yet.
10.7 Highlighting current viewport [1][conformant]
Option in Prefs > Document > Frames > Always show active frame border.
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.
10.9 Relative position of viewport [3][conformant?]
We mainly do the scrollbar, but implementation varies with the OS (We show
relative position on all OS'es though).
11.1 User preferences for input configurations [1][conformant]
The input configurations are displayed with the Ctrl+B command or selectable
from the Help menu.
11.2 View of author-specified input configurations [2][conformant]
When we do ACCESSKEY, this is one of the things we intend to do (see 8.1).
We can do this today with *[accesskey]{content: "(" attr(accesskey) ")"}.
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 mnemnonic (no shift
down, shift up), but have so far desisted in order to reduce modifier keys.
11.4 Minimal input configuration [2][conformant]
We have keyboard and at least one pointing device access method for them.
Keyboard under:
Next/previous enabled element: Tab/Shift+Tab
Activate focused link: Enter
Increase/decrease size of text and graphics: 6/7/8/9/0
[multimedia options skipped]
Forward/back: Alt+RightArrow/Alt+LeftArrow
Enter URI: F2 (or F8)
Add to hotlist: Ctrl+T
View hotlist: F4
Stop loading: ESC
Reload: Ctrl+R/F5 and variants
Refresh: As with Reload
Forward/back one viewport: PgDown/PgUp
Next/previous line: ArrowDown/ArrowUp
11.5 User profiles [2][conformant]
It is possible to have multiple configurations/profiles.This is generally
done through having several opera.ini files and is documented in
<http://opera.com/opera5/>.
11.6 Configuring controls/tool bars [3][conformant]
Everything is configurable, but not all from the WYSIWYG interface (some
opera.ini modification may be required). We have no restore to default
except for overwriting with the original file.
12.1 Product documentation at WCAG Double-A [1][conformant]
Documentation is at the web site <http://opera.com/opera5> and in the help
files.
12.2 Document features that benefit accessibility [1][conformant]
Documentation entrance point at <http://www.opera.com/opera5/special.html>,
as well as F1 > A Return > SSA Return.
12.3 Document default input configuration [1][conformant]
Ctrl+B. Very useful command for any Opera user. Mouse: Help > Mouse.
12.4 Dedicated section for accessability documentation [2][conformant]
See 12.2.
12.5 Document accessability changes with upgrades [2][conformant]
Part of change documentation.
Received on Wednesday, 18 April 2001 20:59:49 UTC