Re: Proposed Set of Needs/Preferences for v1

James Craig <jcraig@apple.com> wrote on 02/19/2013 07:23:35 PM:

> From: James Craig <jcraig@apple.com>
> To: Sangwhan Moon <smoon@opera.com>,
> Cc: Indie UI <public-indie-ui@w3.org>
> Date: 02/19/2013 07:24 PM
> Subject: Re: Proposed Set of Needs/Preferences for v1
>
> On Feb 6, 2013, at 8:33 AM, Sangwhan Moon <smoon@opera.com> wrote:
>
> > On Feb 6, 2013, at 11:30 PM, Andy Heath wrote:
> >
> >> Attached are the proposed preferences for V1 as promised.  They
> are distilled/smplified from the IMS AfA 3.0 preferences.  A very
> few small ones added. Apologies for the slight lateness and for the
> zip file but it was tricky to maintain the style sheets/macros used
> in editing the document without doing that.
> >
> > I've reviewed the document for the last hour, and must point out
> that almost none of
> > these preferences are available on a user agent level
> implementation. Either they
> > need to be propagated from the host OS or accessibility software.
> (in which case,
> > introduces the question of "via what protocol?")
>
> I think we as a group are still discussing two very different
> things, which for lack of better terms, I'll call "wishlist
> preferences" versus "actual preferences." Actual device, browser,
> and AT preferences include things with existing settings like font
> size, colors, and whether or not captions are enabled. What I'm
> referring to as "wishlist preferences" include some things in Andy's
> proposal like "I'd prefer access to an transcript if you have one."
> I don't know of any system that has a preference like this, and on
> the Web it's usually exposed as link near the audio player.
>
> Given that groups like AfA and GPII have taken time to codify these
> "wishlist preferences" I'm not keen on duplicating that effort, and
> was hoping to only specify the more common "actual preferences." For
> the users and tools that need more explicit preferences that are not
> available as part of the system settings, we've discussed allow
> namespaced or prefixed taxonomy keys to be referenced with the preference
key.
>
James,

These are not wishlist preferences. These are already implemented in the
National Science Digital Library. We can not be so myopic as to limit a
user's needs to what is provided as an operating system setting.

You don't know of systems that support preferences like this because you
have not been involved in that work. Just because you have not been
involved in that work does not mean that they are a wish list.

I do not want to limit this work to OS settings. That, to me, would be a
failure of this group. Now, I do agree that some of the preferences, such
as tacticle feedback, could be left out for this round as we don't have an
API to create a vibration from a web page.

Preferences that can be passed to a page author to allow them to deliver
content in different ways is completely in the scope of this work as it
does not require the browser to turn/off a feature in the OS and does not
require an additional API. More importantly, the preference (prefers a
transcript) is easily understood. This is a browser feature setting and
very easy for the user to set. If it becomes important at the OS system
level then the platform owner can decide to move it there. Right now, I see
no need.

We are not duplicating an effort. What you have been provided existed far
before GPII and the GPII preference set is an enormous set of preferences.
We are talking about a small core set of preferences.

> > At the moment, the only information that Opera (sorry for making
> Opera the example)
> > can provide from this perspective is "screen reader active and
> exists?" = true | false.
> > I don't think other browsers are significantly more advanced in
> this regard either.
> >
> > Some operating systems provide this information on a system level,
> but not all OSes
> > provide ways to determine this in a reliable manner. And for
> certain properties (e.g. tactile),
> > I'm afraid there isn't a standardized way to know if such a device
> exists - making it quite
> > challenging to implement for browser vendors.
>
> Agreed.
>
> > Would there be any possibility to revise this to a level where we
> have a common set
> > of things that are readily available on at least the three major
> operating systems?
>
> Which three would those be? ;-) Are you talking about the three main
> desktop operating systems?
>
I don't want to limit the discussion to OS system settings.

> > P.S. Will there be real "browser preferences" in the spec too?
>
> Yes. I was hoping the other proposal would include more of these,
> but it's not too late to start the list here. Please add to it with
> other suggestions.
>
>    String      fontSize (value + unit strings like CSS-formatted
> '12px', or '24pt')
>    String      minFontSize
>
> Note: These are intended mostly as convenience properties.
> Technically it's possible to figure out fontSize and minFontSize
> today, but it's a pain because you need to draw one element at 100%
> the default font size and one at some tiny size, normalize the box
> model, and then check the offsetHeights and adjust for any other
> minor browser differences.
>
>    Color      color
>    Color      backgroundColor
>
> These colors would initially seem like convenience properties, but
> would retain the value of the user CSS or system setting even if
> your web app has overwritten the colors of the root element in the web
view.
>
>    Boolean      deviceMuted
>    Boolean      monoAudio (for example, could toggle with
> accessibility pref or when stereo headphones were connected on
> devices with a mono external speaker)
>
>