FLUID-3671 Screen reader a11y and usability issues with Progress (esp. lack of feedback for screen reader users)
colinbdclark at gmail.com
Wed Sep 29 13:38:55 UTC 2010
Hi Jan and Jonathan,
I completely agree with Jan's point below. We always ship components with good defaults so that implementers don't have to understand all the intricacies of how accessibility works across different technologies. Out of the box, the component should support a wide range of technologies and use cases, and give implementers the tools to stretch beyond when they need to.
Rather than seeing this configurability in Progress as a means for supporting a specific sort of screen reader, I think we should go back and consider the use cases I outlined a few emails back. Eventually, NVDA's bug will be fixed and the question of aria-valuenow vs. aria-valuetext will be entirely a user experience question, as it should be.
Let's not get too caught up in the notion of customizing Progress for one screen reader or another--that's not our goal. Let's focus on the reasons why an implementer might make customization choices for design reasons.
On 2010-09-29, at 9:00 AM, Richards, Jan wrote:
> Hi Jonathon,
> I don't think we can rely on implementers to be aware of the screen reader in use by their user base or the ways screen readers differ. While this might be the case for some intranets, in general I think it would be better for us to give very concrete guidance that maximizes usability for as many screen readers as possible.
> (Mr) Jan Richards, M.Sc.
> jrichards at ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
> Inclusive Design Research Centre (IDRC) | http://inclusivedesign.ca/
> Faculty of Design | OCAD University
>> -----Original Message-----
>> From: fluid-work-bounces at fluidproject.org [mailto:fluid-work-
>> bounces at fluidproject.org] On Behalf Of Jonathan Hung
>> Sent: September 29, 2010 8:01 AM
>> To: Chowdhury, Golam
>> Cc: Hung, Jonathan; fluid-work at fluidproject.org
>> Subject: Re: FLUID-3671 Screen reader a11y and usability issues with
>> Progress (esp. lack of feedback for screen reader users)
>> Thanks Golam.
>> From my understanding a implementor will need to decide why they would want
>> to use valuenow over valuetext. Aside from the *technical* reasons to
>> choose one over the other, what does the implementor gain or lose with
>> either approach?
>> I.e. I am a implementor with a JAWS user base. What are some of the
>> situations where I would want to use valuenow? What are some situations
>> where I would want to use Valuetext?
Technical Lead, Fluid Project
More information about the fluid-work