- From: T.V Raman <raman@google.com>
- Date: Fri, 21 Jun 2013 15:30:28 -0700
- To: schwer@us.ibm.com
- Cc: jcraig@apple.com, jason@jasonjgw.net, public-indie-ui@w3.org
1+. In general, these interfaces should never expose details of
the runtime to this degree --
Richard Schwerdtfeger writes:
> We are really stepping on privacy issues be forcing the user to have to expose the fact they are using a screen reader to be able to use a site.
>
> Sent from my iPad
>
> On Jun 4, 2013, at 1:00 PM, "James Craig" <jcraig@apple.com> wrote:
>
> > On Jun 4, 2013, at 1:43 AM, Jason White <jason@jasonjgw.net> wrote:
> >
> > > James Craig <jcraig@apple.com> wrote:
> > >> What about adding type tokens, such as "screenreader", "magnifier", etc.
> > >
> > > Excellent. An AT can support more than one function.
> >
> > On second thought, I don't think that will work. Part of the reason for splitting these up into separate WebIDL dictionaries is to support a hasFeature() detection method
> similar to DOMImplementation.hasFeature().
> >
> > Just to make sure you're seeing the entire WebIDL blocks, you should be viewing the editor's drafts in a JavaScript enabled browser.
> >
> > So for this existing WebIDL dictionary…
> >
> > dictionary ScreenReaderSettings {
> > boolean? screenReaderActive = null;
> > DOMString? screenReaderName = null;
> > DOMString? screenReaderVersion = null;
> > };
> >
> > …an author could do something like this: (Specific syntax TBD)
> >
> > if (window.settings.hasFeature('ScreenReaderSettings')) {
> > var isScreenReaderActive = window.settings.valueForKey('screenReaderActive');
> > }
> >
> > I think we'd want to set up a different *feature* altogether for 'MagnifierSettings' to standardize properties like zoom level, zoom window size, center point, etc.
> >
> >
>
Received on Friday, 21 June 2013 22:30:55 UTC