Good thoughts - most public (and probably big private too) higher ed
institutions use Section 508 as minimum guidelines for IT, even
though we're not always bound by it legally.
Cheers -
- Oren
On Apr 19, 2006, at 10:46 PM, Matthew Eernisse wrote:
Actually the major Windows screen readers (e.g., JAWS, Window Eyes,
IBM Home Page Reader) can read dynamically generated content just
fine. The problem is in letting the user know that content on the
page has changed, and getting the reader's cursor to the correct
location to start reading the updated content.
One way to handle this problem is to give users with screen readers
the option to receive a JavaScript 'alert' dialog when content
changes (screen readers are aware of modal dialog boxes). This is
obviously not a solution for apps that do polling types of updates,
but it works well for content updates that are user-triggered or
not so frequent. The alert can either contain the content inline if
it's a short message like an error, or can tell the user what part
of the page to go to to see the updated content.
For getting the reader's cursor to the appropriate part of the
page, of course you can use internal page links (a.k.a. 'skip
navigation' links).
Scooby as it is currently designed is nowhere approaching
accessible. The solution for us with Scooby might be the alternate
'low-fi implementation' approach a la GMail, which provides basic
functionality without all the client-side whiz-bang.
It's definitely something we should be thinking about, as
organizations that provide services to the US Federal Government
have to comply with Section 508 of the US Rehabilitation Act, which
mandates IT accessibility.
Matthew
Jeremy Epstein wrote:
That depends on the technical implementation. In fact a lot of
dynamically generated content screws up screen readers,
particularly if they can only read static pages. If that is the
case, all of Scooby and similar calendars are doomed. You could
build a "braille" electronic screen from a matrix of 1024x768
steel pins and activate it with appropriate linear actuators. That
actually might be kinda cool.
:)
Jeremy
Oren Sreebny wrote:
I wonder how the dialog box would work with screen readers for
people with visual disabilities.
- Oren
On Apr 19, 2006, at 6:01 PM, Priscilla Chung wrote:
Here are some mock-ups on how one might access the user
preference in Scooby.
http://wiki.osafoundation.org/bin/view/Journal/
ScoobyUserPreferences
I have two proposals on where the user preferences can appear:
in a dialogue box OR in a preferences page.
Although currently for 0.2 there is a very little content in
what we're planning on implementing. Keep in mind, this may grow
into a much a larger set of preferences. For example changing
the skin/color of the web application, working hours, language,
holidays, subscriptions including public calendars or publishing
the user's calendar, feedback etc. A more fomal list will be
created for future planning for Scooby.
Feel free to add your own pros and cons to the list. I may not
have covered everything.
Dialog box
Pros:
+ Dialog box can make the appication look good, especially for
small forms, but they need to be executed well or they become
VERY frustrating
+ The focus is on the same page without jumping back and forth
from page to page.
Cons:
+ Limited amount of space and may be difficult to cram a lot of
information as the product grows
+ If the dialogue box cannot be moved or closed, it can really
frustrate the user Preferences Page
Pros:
+ Wow. Look at all the white space. Remember though, as the
product grows there will be more space in the preferences area
and development/design won't be confined to a small box.
+ A larger set of preferences which may include changing the
skin/color of the web application, working hours, language,
holidays, subscriptions including public calendars or publishing
the user's calendar, feedback etc.
Cons:
+ Jumping to and from the calendar.
---
My personal recommendation is to have a preferences page. -
Priscilla_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
