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

Test run of User Agent (Opera 5.1/Win)

From: Jonny Axelsson <jax@opera.no>
Date: Thu, 19 Apr 2001 02:56:18 +0200
Message-Id: <200104190059.f3J0xb303087@mail.opera.no>
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 GMT

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