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. Colin 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. > > Cheers, > Jan > > -- > (Mr) Jan Richards, M.Sc. > [email protected] | 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: [email protected] [mailto:fluid-work- >> [email protected]] On Behalf Of Jonathan Hung >> Sent: September 29, 2010 8:01 AM >> To: Chowdhury, Golam >> Cc: Hung, Jonathan; [email protected] >> 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? >> >> -Jonathan --- Colin Clark Technical Lead, Fluid Project http://fluidproject.org _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
