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
