OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [docbook] http://docbook.sourceforge.net/ problem


Hi,

> But I will concede that I hadn't considered the case of how a user
> without a mouse is meant to navigate through it.


DaveP is correctly pointing to the accessibility issue; but I don't 
think that to adjust design
to the needs of visually-inpaired and without a mouse is a right 
approach. Those who don't know English
  but interested in DocBook will still won't be able to read the page. 
There are more people who don't
know English but use computers with mice and visual displays than those 
who do but use screen readers.

One solution would be to provide the page content in all languages, for 
the sake of accessibility. Another one
would be to set up computer translators capable enough to translate the 
text into the user's language.

With accessibility for visually impaired, the situation is similar. One 
is to make the design so simple that the
only side that benefits is authors of bad screen readers. Another one 
is to make screen readers understand
JavaScript and provide alternative means for navigation. With the first 
approach, the majority suffers, including
the blinds: they can't access most sites, because not all sites are 
careful enough to provide content for bad
screen reading programs. With the second approach, everyone wins, 
because it allows most people to access
most sites in the most pleasant way, and boosts software development 
and advances in information science.

Current accessibility tools are bad, and it is possible to make than 
better. I believe that the way to accessibility
for everyone is making tools better, not trimming down the design.

> But there will be a lot more websites and "web apps" moving to
> relying on Javascript and Ajax behavior -- drag and drop, multiple
> windows, interactive features -- that will not degrade gracefully
> in such a way

This is a separate issue. rico is a good tool by intent for cases when 
one needs to use dynamic interfaces on a web page. It is not so good by 
implementation because it fails to work consistently in different 
browsers. But using JavaScript-based dynamic interfaces with 
drag-n-drop/multiple windows/interactive features is only justified 
when a simple point-and-go/single view is single page/static text 
approach does not work.

Much in the same way as dynamic gifs and running status lines were 
fashionable in mid-nineties, JavaScript and interface effects are 
popular now just because it finally almost works and designers are 
hungry to use all of it in every next page. This fashion will hopefully 
pass soon, and most pages will return to simple and useful design; 
while AJAX will be used for pages which are not just pages but complex 
application with web browser interfaces.

David



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]