Mailing List Archive

On Don, 2003-01-02 at 03:14, rose.parks@att.net wrote:

Happy 2003!

> I have been hoping that someone else would bring up the issue of
> accessibility in Wikipedia. Yet, having read over 20 e-mails on the problem of
> our many and multi-colored links, I saw no mention of this issue. If Derek
> Moore is having trouble with these links, try to imagine how useless these
> color schemes are to a blind user. Do all members agree with him, that since he
> is in a color blind minority, no attempt should be made to remedy the situation?

I am all for making Wikipedia more accessible, but not if that happens
at the disadvantage of the majority of users. Adding stuff like CSS for
Braille readers and text-to-speech synthesis is reasonable. BTW, if you
disable the "Highlight links to empty topics" user preference, broken
links are rendered

Nonexistent Page?

instead of

Nonexistent Page

in red. This is the original wiki style, which is horrible from a
usability perspective, but works better for text-to-speech synthesis and
the like.

If we add the CSS stuff, we need to figure out how to automatically do
this for tables, which are currently not standardized on Wikipedia (i.e.
table designs vary a lot). This would be a good thing to keep in mind
when we address table support in Wiki-syntax.

Regards,

Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de

rose.parks@att.net wrote:
> I have been hoping that someone else would bring up the issue
> of accessibility in Wikipedia. Yet, having read over 20 e-mails on
> the problem of our many and multi-colored links, I saw no mention of
> this issue.

I fully agree with Ruth Ifcher that this should be a priority, and
that we should stick to display standards that are simple and
functional rather than beautiful.

> I think at this stage in Wikipedia's development, some of the
> basic accessibility features might be incorporated in our software -
> like not depending on color coding to convey information, and adding
> descriptions to all images. I am strongly in favor of such
> features. Unfortunately, my programming skills are not nearly strong
> enough to try to add any. Hopefully, some of the developers will
> agree that accessibility is important and will be willing to work on
> adding some of these features.

In my opinion, you are absolutely right. This is something that would
be easy to forget, but the wikipedia mission of open education for all
is consistent _only_ with efforts to bring our work to everyone in as
fully accessible a manner as possible.

Ruth, I encourage you to keep complaining about this, lest we forget!

--Jimbo

Erik Moeller wrote:
> I am all for making Wikipedia more accessible, but not if that happens
> at the disadvantage of the majority of users.

But many of the changes that break accessibility aren't really to the
_advantage_ of the majority of users, except in the sense of
beautification.

I think that the *default* wikipedia should be *highly accessible* in
the sense put forward by Ruth. Everything about the site should be in
line with normal standards, and nothing should astonish anyone.

Gorgeous fancy stuff can be left optional.

You didn't quite say anything like this, but there's a risk here of an
attitude: "If the blind people don't like the default underlining,
they can always go into the options settings and do this, or they can
always write their own CSS style sheet to do that." That's a bad
attitude. Blind people just won't bother. Color blind people who
find the site unusable aren't likely to bother, either. They'll just
go away sad.

--Jimbo

Jimmy Wales wrote:

>rose.parks@att.net wrote:
>
>
>>I think at this stage in Wikipedia's development, some of the
>>basic accessibility features might be incorporated in our software -
>>like not depending on color coding to convey information, and adding
>>descriptions to all images. I am strongly in favor of such
>>features. Unfortunately, my programming skills are not nearly strong
>>enough to try to add any. Hopefully, some of the developers will
>>agree that accessibility is important and will be willing to work on
>>adding some of these features.
>>
>>
>
>In my opinion, you are absolutely right. This is something that would
>be easy to forget, but the wikipedia mission of open education for all
>is consistent _only_ with efforts to bring our work to everyone in as
>fully accessible a manner as possible.
>
>
Concerning images:
AFAIK, all the information/description/source stuff should go into the
[[image:xyz.jpg]] text, right?
And, if I remember correctly from my futile attempts with the old
Nupedia software, some "read aloud"-browsers (most of them, actually)
can read aloud the "alt" tag of an image.

So, how about using the [[image:xyz.jpg]] text in the "alt" tag of the
image when displayed?
Of course, there'd be some downsides:
* An extra database access for getting the text.
* Extra text being transmitted (longer loading time).
* If you put the mouse cursor on the image, the "alt" text will appear.
OTOH, that might actually be a good thing.

Magnus

On Don, 2003-01-02 at 15:22, Jimmy Wales wrote:

> You didn't quite say anything like this, but there's a risk here of an
> attitude: "If the blind people don't like the default underlining,
> they can always go into the options settings and do this, or they can
> always write their own CSS style sheet to do that." That's a bad
> attitude. Blind people just won't bother. Color blind people who
> find the site unusable aren't likely to bother, either. They'll just
> go away sad.

1) The site is not unusable if the broken/non-broken indicator is not
displayed.

2) Using an indicator like the previous ugly ? as the default has a
negative usability effect on a much larger number of users.

3) The proper thing to do is to enable CSS for text-to-speech and
Braille readers in order to transmit the link state information without
a notable effect on average users.
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de

On 02 Jan 2003 15:55:47 +0100, Erik Moeller
<e.moeller=Ui4TQZZ8pVAPyMaTEpOvjQ@public.gmane.org> wrote:

(repeating this post to keep it in the correct list/newsgroup - sorry!)

> 1) The site is not unusable if the broken/non-broken indicator is not
> displayed.

agreed

> 2) Using an indicator like the previous ugly ? as the default has a
> negative usability effect on a much larger number of users.

Agreed - because there are so many linked words within the main text,
interrupting the text flow is bad.
>
> 3) The proper thing to do is to enable CSS for text-to-speech and
> Braille readers in order to transmit the link state information without
> a notable effect on average users.

Proper, but in all practicality, pointless. I have done quite a bit of
testing of websites in various talking browsers. Most use the IE rendering
engine and simply read the text that ends up on screen. They are almost
totally dependent on punctuation, and don't respect breaks in HTML (even
list items or table cells). Thus the entire left-hand bar on Wikipedia
would be read as one long sentence - "Main page recent changes random page
current events" etc. None of them know anything about CSS. I believe there
is one project (currently only Linux-based) to build a browser which
understands aural css. Note that I have not tested some of the expensive
products like Jaws, but they make no claims in their promotional material
that suggest they are anything beyond a screen reader like all the rest.
 
assist non-visual browsers is to ensure that the page content comes as
early as possible in the source code. Else on every page the user has to
wade through the same long list of navigation. This can be achieved via CSS
positioning. As a bonus, promoting the page content to the start of the
source code gives a considerable boost to search engine rankings!
As an example, try http://www.electec.co.nz/electrotec.mv - a site that
looks graphics heavy and uses DHTML menus etc. but remains accessible. Try
it in a screen reader, Lynx, or Opera with images and stylesheets off. Note
that I have used css to "hide" punctuation in the navigation and lists -
hence screen readers make a reasonable job of them.
Incidentally, all screen readers I've tried have a separate function to
read all the links on a page, so putting content first does not mean you
have to listen to the entire page before you can navigate anywhere else.
Most talking browsers are aiming to be useable with only half a dozen keys
to control them.

--
Richard Grevers
Christchurch, New Zealand

On Don, 2003-01-02 at 19:43, Richard Grevers wrote:
> Proper, but in all practicality, pointless. I have done quite a bit of
> testing of websites in various talking browsers. Most use the IE rendering
> engine and simply read the text that ends up on screen. They are almost
> totally dependent on punctuation, and don't respect breaks in HTML (even
> list items or table cells). Thus the entire left-hand bar on Wikipedia
> would be read as one long sentence - "Main page recent changes random page
> current events" etc. None of them know anything about CSS.

I've done a search a few months ago and found a couple that claimed to
be aural CSS compliant. Can't find them again, though. This may be the
Linux project you referred to: http://emacspeak.sourceforge.net/

I don't know if these are actually used. But it seems to me that it's a
better long-term plan to use these standards rather than to accomodate
the idiosyncratic behavior of current speech browsers.

I'd also like to get feedback from blind/disabled users on this.

Regards,

Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de

Hi Erik Moeller and Members,

I did a search on "aural + CSS" in google and found that the W3C has a
working group on this subject, as of 2/2001, that 2 members had their own
implementations of a browser using aural CSS, and that IBM's Home Page Reader
is referred to as a aural CSS-enabled-wrapper for Internet Explorer 5. I
realize by the date that this is not as recent as one would hope, but there is
nothing newer on the subject.
Home Page Reader is available as a 30 day trial download from IBM (or was.)
The search also lead to a number of tutorials on aural CSS.
For W3C working group notes see:

http://www.openebook.org/members/ps/20010214.htm

As Ever,

Ruth Ifcher

--

> On Don, 2003-01-02 at 19:43, Richard Grevers wrote:
> > Proper, but in all practicality, pointless. I have done quite a bit of
> > testing of websites in various talking browsers. Most use the IE rendering
> > engine and simply read the text that ends up on screen. They are almost
> > totally dependent on punctuation, and don't respect breaks in HTML (even
> > list items or table cells). Thus the entire left-hand bar on Wikipedia
> > would be read as one long sentence - "Main page recent changes random page
> > current events" etc. None of them know anything about CSS.
>
> I've done a search a few months ago and found a couple that claimed to
> be aural CSS compliant. Can't find them again, though. This may be the
> Linux project you referred to: http://emacspeak.sourceforge.net/
>
> I don't know if these are actually used. But it seems to me that it's a
> better long-term plan to use these standards rather than to accomodate
> the idiosyncratic behavior of current speech browsers.
>
> I'd also like to get feedback from blind/disabled users on this.
>
> Regards,
>
> Erik
> --
> FOKUS - Fraunhofer Insitute for Open Communication Systems
> Project BerliOS - http://www.berlios.de
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikitech-l