|
Implementation Review of Opera 5.12
Implementation Home Page
| Please read
disclaimer
before reviewing this report
Evaluation Information
|
Evaluation Summary
|
Checkpoint Details
Subject: Opera 5.12
Operating System: Microsoft Windows
Formats: HTML 4.01, CSS1 and CSS2
Date: 21 August 2001
Guidelines: User Agent Accessibility Guidelines ( 31 July Working Draft )
-
Reviewer
-
Name: Jonny Axelsson and Harvey Bingham
-
Affliation: Opera Software, Bingham Associates
-
Phone: ?,1-781-862-6908
-
E-mail: jax@opera.no, hbingham@acm.org
Not Rated
Total checkpoints: 22
Not Implemented
Total checkpoints: 0
Poor Implementation
Total checkpoints: 11
Good Implementation
Total checkpoints: 2
Very Good Implementation
Total checkpoints: 9
Complete Implementation
Total checkpoints: 32
Not Applicable
Total checkpoints: 14
Rating: VG
Comments
- 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.
- Through windows, menus and pointing devicet
(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.
- Contextual menus and pointing device actions not using OS
menus. This is the poorest set, but should be more than sufficient for
normal browsing. A couple of commands are *only* available
through context menus (like validate HTML), This is a UI and WAI bug
and should be fixed. Note 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.]
Rating: G
Comments
- This we do (with the exception of native voice input), and
it is to a large extent configurable.
- Does not appear to provide keyboard access to pointing device event handlers. Need to check with Opera.
Rating: C
Comments
- We don't use images or sounds for anything else than
ancillary/illustrative purposes (e.g. email filters may optionally
have a sound added).
- HB: Implication, do use text equivalents.
Rating: NR
Comments
Rating: NR
Comments
Rating: NR
Comments
- ALT for IMG:
- TITLE for IMG element:
- LONGDESC for IMG element:
- content of OBJECT element:
- ALT for AREA element:
- ALT for INPUT element:
- ACRONYM element:
- ABBR element:
- SUMMARY for TABLE:
- TITLE for FRAME:
- LONGDESC for FRAME:
- NOFRAME for FRAME:
- NOSCRIPT for SCRIPT:
Rating: NR
Comments
- 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"?
- HB: Pause/Resume can achieve this
Rating: NR
Comments
- 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.
Rating: NA
Comments
- At this point in time no support for these.
Plug-ins might be, but we'll have no direct control of these.
Rating: VG
Comments
- 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.
- HB: tidy-like inference and tag completion is not done.
Rating: C
Comments
- 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.
Rating: NR
Comments
Rating: NR
Comments
- HB: Source can be viewed.
Rating: G
Comments
- 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.
- HB: Lack of Unicode support limits languages that can be supported.
Rating: NA
Comments
- *{background-image: none !important}, also a separate option.
I am confused by "option to alert the user".
- HB: Lack of support for/control over background images: not
clear what happens. The image control is show: no images, cached images
only, or all images. No help mention of background images.
Rating: C
Comments
- 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?
Rating: VG
Comments
- 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.
Rating: VG
Comments
- 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.
Rating: C
Comments
- 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.
Rating: NR
Comments
Rating: C
Comments
- The G command in Opera. Each separate image can be handled by
the context-sensitive menu.
- HB: Image display control choices are to show: no images,
cached images only, or all images.comment>
Rating: C
Comments
- 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).
Rating: C
Comments
- File > Preferences > Documents > User fonts.
- HB: Presentation Mode Choices are separate, user and/or
document choices. [Choice of which takes precedence for all, user
or document.]
Rating: C
Comments
- File > Preferences > Documents > colors.
- HB: Choices are separate, user and/or document choices.
[Choice of which takes precedence for all, user or document.]
Rating: NA
Comments
- Multimedia is done through external applications.
Rating: NA
Comments
- Multimedia is done through external applications.
Rating: NA
Comments
- Multimedia is done through external applications.
Rating: NA
Comments
- Multimedia is done through external applications.
Rating: NA
Comments
- Multimedia is done through external applications.
Rating: NA
Comments
- Multimedia is done through external applications.
Rating: NA
Comments
- Multimedia is done through external applications.
Rating: NA
Comments
- Multimedia is done through external applications.
Rating: NR
Comments
- 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.
Rating: NR
Comments
- 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.
Rating: NR
Comments
- 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.
Rating: NR
Comments
- 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.
Rating: NR
Comments
- 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.
Rating: C
Comments
- This we do.
- HB: File > Preferences > Document > Document CSS and
User CSS
- HB: Choices are separate, user and/or document choices.
[Choice of which takes precedence for all, user or document.]
Rating: C
Comments
- 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.
Rating: C
Comments
- Apart from the possibilities given by the OS, new windows can
be opened in the background.
Rating: NA
Comments
- 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?".
Rating: NR
Comments
- HB: Can select material, then scroll it out of sight. It
remains selected.
Rating: NR
Comments
- We have no way today to halt script-based 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.
Rating: P
Comments
- Opera doesn't recognize fee links.
- HB: There is no requirement that link URL is self-descriptive
for need of fee link.
Rating: NR
Comments
- 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.
Rating: P
Comments
- I have serious issues with this section 6.1 thru 6.10. 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. No DOM support yet.
Rating: P
Comments
Rating: P
Comments
Rating: P
Comments
- HB: Many controls can be manually established. Infer from
above 6.1 that these are not available programmatically.
Rating: P
Comments
- HB: Many controls can be manually established. Infer from
above 6.1 that these are not available programmatically.
Rating: C
Comments
- HB: Uses OS keyboard support, plus full set of keyboard
shortcuts.
Rating: P
Comments
- HB: No Unicode support. No DOM support.
Rating: P
Comments
- HB: No DOM access. Does support CSS.
Rating: NR
Comments
- HB: "timely" is most vague. No programmatic accesses
so no exchanges either.
Rating: C
Comments
- We have mouse gestures that might theoretically interfere
with similar applications, but they are optional.
- HB: Mouse gestures take training, disorienting at first,
effective.
Rating: C
Comments
Rating: C
Comments
Rating: C
Comments
Rating: NR
Comments
- 8.1 and 8.2 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.
- HB: Following are explicit possibilities to be rated, a composite
would be hard.
- HTML: CAPTION element (TABLE):
- HTML: THEAD element (TABLE)
- HTML: TBODY element (TABLE)
- HTML: TFOOT element (TABLE)
- HTML: COLGROUP element (TABLE)
- HTML: COL element (TABLE)
- HTML: SCOPE attribute (TABLE)
- HTML: HEADERS attribute (TABLE)
- HTML: AXIS attribute (TABLE)
- HTML: TABINDEX attribute
- HTML: ACCESSKEY attribute
- CSS: TEXT-INDENT
- CSS: TEXT-ALIGN
- CSS: WORD-SPACING
- CSS: LETTER-SPACING
- CSS: FONT-STRETCH
- CSS: MARGIN
- CSS: FLOAT
- CSS: POSITION
- CSS: !IMPORTANT
- CSS: SYSTEM FONTS
- CSS: SYSTEM COLORS
- CSS: list types
- CSS: OUTLINE
- CSS: :before, :after, content
- CSS: volume
- CSS: speak
- CSS: pause, pause-before, pause-after
- CSS: cue, cue-before, cue-after
- CSS: play-during
- CSS: azimuth, elevation
- CSS: speech-rate
- CSS: voice-family
- CSS: pitch
- CSS: pitch-range
- CSS: stress
- CSS: richness
- CSS: speak-punction
- CSS: speak-numeral
- HB: The last ten CSS-labeled features to be considered are
actually from CSS-2.
Rating: VG
Comments
- HB: Opera5.12 does attempt this. Detailed assessment is
impractical. Claims support for: HTML 4.01, XML 1.0, XHTML 1.0, CSS Level
1 and level 2, WAP and WML, ECMA-262 (ECMAScript) and HTTP/1.1.
Also Java Runtime Environment directly (and is part of installation),
not as a plugin.
Rating: C
Comments
- By pressing "3" you can navigate between frames in a window. By
pressing "1"/"2", you can navigate to previous/next window.
Rating: C
Comments
- HB: Preferences allow user interface tailoring.
Rating: C
Comments
- 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.
Rating: C
Comments
- HB: Back allows those for session. Preferences allow restore
from prior session. Also a Hotlist.
Rating: C
Comments
- 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.
Rating: NR
Comments
- 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.
- HB: Not clear what former checkpoint 9.4 answer above now
applies to.
Rating: C
Comments
- 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.
- HB: not clear the optimality measure. Included this
material here, as this checkpoint appears as the one most
dealing with user means for navigation.
Rating: C
Comments
- Both move the viewport and continue search. We don't search
source code, but the associated source code viewers will.
Rating: C
Comments
- The keyboard navigation in 9.7 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.
Rating: P
Comments
- The navigational elements aren't user configurable.
Rating: P
Comments
- 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.
Rating: VG
Comments
- This point relates to *default* highlighting, otherwise some
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.
Rating: C
Comments
- Prefs > Document and user CSS.
Rating: NR
Comments
Rating: P
Comments
- 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.
Rating: VG
Comments
- 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).
- HB: rating would be C except that Opera doesn't recognize
fee links.
Rating: C
Comments
- Option in Preferences > Document > Frames > Always
show active frame border.
Rating: C
Comments
- HB: There is a progress bar.Opera is known for its speed.
Rating: NA
Comments
- If customizable keyboard shortcuts is what is meant here:i
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.
- HB: I note that for some actions, there are multiple choices
of Keyboard Shortcuts.
Rating: NA
Comments
- HB: No such choices are available, see 11.1, but there
is choice of document vs user bindings as having precedence.
Rating: NA
Comments
- HB: fixed set of keyboard shortcut bindings.
Rating: C
Comments
- HB: true for pre-selected set of access actions.
Rating: VG
Comments
- 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
Rating: NR
Comments
- 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/>.
Rating: NR
Comments
- 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.
Rating: C
Comments
Rating: C
Comments
- Documentation is at the web site <http://opera.com/opera5>
and in the help files. Claims WCAG 1.0 Double-A.
- HB: Help files separate for contents F1, and for keyboard Ctrl-B.
Contents tab order is Index, Features, (and 8 more that UA doesn't
require.)
Rating: C
Comments
- Ctrl+B gets Keyboard Shortcuts. Very useful command for any
Opera user. Mouse: Help > Mouse
- HB: Mouse Gestures, activated by right-mouse button, sense
discrete mouse directional motion sequences.
Rating: C
Comments
- Part of change documentation.
Rating: VG
Comments
- Opera is better than other Internet browsers with regards to
accessibility on a number of key points.
- HB: Material has uncertain relation to accessibility.
File > Preferences > Accessibility: has two sections with
toggles:
- HB: 1) Mouse options toggles: Enable mouse gestures, Adjust mouse
button navigation for left-handed configuration, and Underline
mouse hover list items.
- HB: 2) Keyboard options include: Enable auto completion
dropdown, Menu style item selection in Hotlist window, and Screen reader
compatible menus.
- HB: Many of the previously addressed issues from different
preferences affect the overall accessibility assessment. The lack of
exposure via DOM to speech technology may be a problem.
Jon Gunderson (Jon Gunderson)
Ian Jacobs (ij@w3.org)
Last revised: $Date: 2002/02/27 22:31:42 $
|
Copyright©2000-2001
W3C® (
MIT,
INRIA,
Keio), All Rights Reserved. W3C
liability,
trademark,
document use and
softwarelicensing rules apply.