- From: Harry Loots <harry.loots@ieee.org>
- Date: Tue, 14 Aug 2012 11:39:24 +0200
- To: Adam Cooper <cooperad@bigpond.com>
- Cc: "Patrick H. Lauke" <redux@splintered.co.uk>, w3c-wai-ig@w3.org
- Message-ID: <CA++-QFcCA=oymWy=hjOXs1QyMwQODBokhmb4qM=_Uw2wa6gzeg@mail.gmail.com>
Hi Adam I'm of the opinion that it is in the same category as increase/decrease text size features on webpages. They're usability rather than AT features. They may be useful for some people, but they are not intended to help people who already use AT. Perhaps its greater benefit is that it should improve the underlying quality of code thereby making it easier for AT users to use. If websites do support these features, then they will should to have been designed and developed with these features in mind. Thus, a user using magnification software or even browser zooming/magnifying may benefit from the development process. Similarly users using text-to-speech should benefit from the extra work that should have been done to make it BrowseAloud or ReadSpeak friendly. Regards, Harry On 12 August 2012 05:03, Adam Cooper <cooperad@bigpond.com> wrote: > Hi Patrick, > > Thanks for your insights. I agree that these 'features' can interfere with > a user's assistive technology and that there might be issues with obtaining > plug-ins etc. which is why I asked the questions about meeting conformance > requirements. > > I am wondering whether conformance requirements 4 and 5 are satisfied. Are > these accessibility supported technologies? Are the > accessibility-supported user agents really freely available etc.? are they > non-interfering? > > More generally, are they media alternatives? Assistive technology? > Audio-only? How are they to be treated in content auditing? > > P.S. love the </rant> > > Cheers, > Adam > > -----Original Message----- > From: Patrick H. Lauke [mailto:redux@splintered.co.uk] > Sent: Saturday, August 11, 2012 8:02 PM > To: w3c-wai-ig@w3.org > Subject: Re: in-page text-to-speech > > On 11/08/2012 06:34, Adam Cooper wrote: > > I have encountered some sites recently that use in-page text-to-speech. > > ReadSpeaker and BrowseAloud are two that spring to mind. I'd really > > appreeciate any thoughts about these kinds of supplemental > > technologies, particularly with regards to meeting the WCAG 2.0 > conformance requirements. > > An example of one of these TTs implementations is at: > > http://www.health.vic.gov.au/news/new-laws-protect-victorians-in-suppo > > rted-r > > esidential-services.htm > > I'm generally quite wary of these sorts of "features". A user that truly > needs text-to-speech will need it at an OS level, not on a page-by-page > basis. So they're likely to have software installed that makes their > overall experience on their machine accessible to them. > > If users already have AT available, additional "self-voicing" features on > a site can actually end up being quite confusing as they can run in > parallel to the user's regular voice feature. > > The use case that's generally then mentioned it "but what if it's a user > that is not on their own machine...say in a cafe or library?" and true, in > those edge cases, this may be a valid situation (though BrowseAloud, for > instance, actually requires a plugin installed, which you can't do, as an > end user, on cafe/library machines). > > I'm not sure if anything's changed with BrowseAloud specifically, but I > had some "issues" with them in the past (a "rogue" employee astroturfing > some accessibility forums, pretending to be dyslexic > http://www.accessifyforum.com/viewtopic.php?p=22009 - oh, and when their > marketing claimed that they were recommended by the PAS78 guidance in the > UK > http://www.webstandards.org/2006/05/11/all-aboard-the-pas-78-gravy-train/ > ). > Also, BrowseAloud specifically (again, unless they've changed the model) > is a plugin that actually works on *any* website, but it includes a > whitelist of sites where it's allowed to work. By buying the BA service, > you're effectively getting your URL into that whitelist. Which just sounds > more like extortion to me... > > Just as with things like "should I provide text resizing and colour > changing widgets on my website", there certainly can be a benefit to some > users, but the fact that you're providing a site-specific solution, that > only works within your pages, and probably only marginally benefits some > absolute edge-case users, should be taken into consideration. It definitely > isn't "required" as such, AND in my mind doesn't absolve you from any other > requirements for conformance (in fact, BrowseAloud and ReadSpeaker etc work > best with an "accessible" - from a technical point of view - site, so the > site should already meet WCAG conformance anyway ... they just offer a > layer that goes above and beyond). > > </rant> > > Cheers, > > P > -- > Patrick H. Lauke > ______________________________________________________________ > re·dux (adj.): brought back; returned. used postpositively [latin : re-, > re- + dux, leader; see duke.] > > www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com| > http://flickr.com/photos/redux/______________________________________________________________ > twitter: @patrick_h_lauke | skype: patrick_h_lauke > ______________________________________________________________ > > > > >
Received on Tuesday, 14 August 2012 09:39:52 UTC