E-mail List Archives
Thread: Opera 7 beta2, even more help to check accessibility
Number of posts in this thread: 6 (In chronological order)
From: Timothy Luoma
Date: Fri, Dec 20 2002 2:28PM
Subject: Opera 7 beta2, even more help to check accessibility
No previous message | Next message →
Opera 7 beta 2 is another big step forward for those interested in checking
their pages for accessibility.
Opera 7 introduces a "Links" panel in the "Hotlist" (Press F4) which lists
all the links in a given page. It supports the TITLE element for these
links. Very handy for checking to see if your links make sense when read
out of context (or for using sites that have turned off underlining of
links without enough contrast to see where links are.
Alternate Stylesheets are also supported.
Oepra 7 beta 2 comes with several user stylesheets built in, many of which
are helpful for accessibility:
Emulate Text Browser
Disable Tables
Accessibility layout
High Contrast (white on black or black on white)
And one very cool one called "Show Structural Elements" which counts Font
tags and Nested Tables in addition to giving you a nice view of the layout
of the document. (Checkout http://microsoft.com/ in that one!)
One minor regression (remember it IS beta software) is that the Screen
Reader Compatible Menus option is not currently working, but Opera is aware
of this flaw.
On the other hand, Opera has made it much easier for users to customize the
User Interface of Opera, including reconfiguring menus and adding your own
keyboard shortcuts, thus making it easier for people to compensate for any
difficulties they might have using the default UI.
If you would like to check it out, visit http://www.opera.com
TjL
--
Timothy Luoma < = EMAIL ADDRESS REMOVED = >
30 Days to Becoming an Opera (6) Lover
http://tntluoma.com/opera/lover/
(an Opera7 version will follow once it is officially released)
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Tom Gilder
Date: Sat, Dec 21 2002 9:18AM
Subject: Re: Opera 7 beta2, even more help to check accessibility
← Previous message | Next message →
On Friday, December 20, 2002, 9:18:06 PM, Timothy Luoma wrote:
> On the other hand, Opera has made it much easier for users to customize the
> User Interface of Opera, including reconfiguring menus and adding your own
> keyboard shortcuts, thus making it easier for people to compensate for any
> difficulties they might have using the default UI.
It's a shame that Opera haven't provided (and I doubt will provide) a
UI to edit such things though - my guess is that editing INI files
using a screenreader *really* isn't fun...
--
Tom Gilder
http://tom.me.uk/
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Timothy Luoma
Date: Sat, Dec 21 2002 10:14AM
Subject: Re: Opera 7 beta2, even more help to check accessibility
← Previous message | Next message →
On Sat, 21 Dec 2002 15:58:34 +0000, Tom Gilder < = EMAIL ADDRESS REMOVED = > wrote:
> On Friday, December 20, 2002, 9:18:06 PM, Timothy Luoma wrote:
>> On the other hand, Opera has made it much easier for users to customize
>> the
>> User Interface of Opera, including reconfiguring menus and adding your
>> own keyboard shortcuts, thus making it easier for people to compensate
>> for any difficulties they might have using the default UI.
>
> It's a shame that Opera haven't provided (and I doubt will provide) a
> UI to edit such things though
So Opera is criticized for not making something *easier*
when the other two have no way to do it at all?
Shame on them for trying, I guess.
> my guess is that editing INI files
> using a screenreader *really* isn't fun...
They are plain text files, I would expect most folks using a screen reader
would find that a common experience (editiing a text file). How would a
GUI make this easiesr for them?
TjL
--
Timothy Luoma < = EMAIL ADDRESS REMOVED = >
30 Days to Becoming an Opera (6) Lover
http://tntluoma.com/opera/lover/
(an Opera7 version will follow once it is officially released)
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Tom Gilder
Date: Sat, Dec 21 2002 11:30AM
Subject: Re: Opera 7 beta2, even more help to check accessibility
← Previous message | Next message →
On Saturday, December 21, 2002, 5:04:15 PM, Timothy Luoma wrote:
> > > Opera has made it much easier for users to customize the User
> > > Interface of Opera, including reconfiguring menus and adding
> > > your own keyboard shortcuts
> >
> > It's a shame that Opera haven't provided (and I doubt will provide) a
> > UI to edit such things though
>
> So Opera is criticized for not making something *easier* when the
> other two have no way to do it at all? Shame on them for trying, I guess.
Having editable menus and shortcuts is excellent. Having to edit INI
configuration files is not.
> > my guess is that editing INI files using a screenreader *really*
> > isn't fun...
>
> They are plain text files, I would expect most folks using a screen reader
> would find that a common experience (editiing a text file). How would a
> GUI make this easiesr for them?
They're plain-text files, yes, but not exactly the easiest thing to
edit (even for me). A simple UI would allow jumping to specific
shortcuts and allow listing of everything you can assign a shortcut
to. It would be easier for everyone.
--
Tom Gilder
http://tom.me.uk/
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Frank Gaine
Date: Tue, Dec 31 2002 7:40AM
Subject: What is Dynamic Content?
← Previous message | Next message →
Group,
quick question, could anyone give me examples of 'dynamic content' as it
relates to 6.2 of the WAI Checkpoints? That is "Ensure that equivalents for
dynamic content are updated when the dynamic content changes."
Kind Regards
Frank
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Jukka K. Korpela
Date: Wed, Jan 01 2003 7:28AM
Subject: Re: What is Dynamic Content?
← Previous message | No next message
On Tue, 31 Dec 2002, Frank Gaine wrote:
> could anyone give me examples of 'dynamic content' as it
> relates to 6.2 of the WAI Checkpoints?
The techniques notes that the checkpoint refers to
discuss applets and "programmatic objects", frames, and
scripts, but it's difficult to say what kinds of content is
really regarded as dynamic here. The glossary of the document
does not define "dynamic", except in the sense that the phrase
(marketing term) "Dynamic HTML" is described.
(Guideline 4 says: "Clarify natural language usage", but the
more specific guidelines, or "checkpoints" as they call them,
are rather technical in nature and miss the most important point:
terms that might not be understood by readers or that might
be misunderstood should be defined or explained, within reasonable
limits - and phrases commonly used as vague buzzwords surely
fall within the limits. The guidelines document itself actually tries to
explain the terms it uses, via the glossary mainly, but there are
important omissions, like "dynamic content".)
Etymologically, "dynamic" (from Greek "dynamis" 'power, force') means
'powerful, powered'. But it's become a buzzword that often means that
something _changes_. (The connection is that changes can often be thought
of as caused by some force.) In the Web context, some kind of interaction
is usually implied, either with the user or with something external to a
Web page, such as a database, newsfeed, or camera. So it could be almost
anything; it's the opposite to a static page, such as a simple HTML
document, the content of which does not change unless edited by the page
author. (This is a bit odd. A page is probably considered as "dynamic", if
it is generated from a database whenever a browser requests for the page,
and "static" if it is changed only so that a person edits it directly.
Yet, the actual update rate could be once a year for the former, once a
day for the latter.)
But in the context "Ensure that equivalents for dynamic content are
updated when the dynamic content changes", we probably need no go very
deep into this conceptual mess. It actually boils down to a simple
principle that can be written more generally: Make sure that the fallback
content (to be used in graceful degradation) is as up-to-date as the
primary content. For example, if you write an applet, you should specify
an adequate fallback for non-Java presentations (though, in special cases,
the fallback content could be empty, just as alt="" can be adequate);
checkpoint 6.2 reminds that if you change the applet, you should also
change the fallback accordingly.
The practical importance of this rule stems from the fact that even if
authors realize why fallback content is needed, they often tend to regard
it as something extra, to be handled with the little finger of one's left
hand (oops, I mean 'less skilled hand' :-)). It's easy to forget to update
it when in hurry and rush, i.e. in the normal condition of Web authors.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/