Re: User Contexts: identifying assistive technologies

Yes, that is similar to what we had proposed (although not in that detail)
in AccessForAll. We had an ATInteroperable property which stated:


A preference for resources that is compatible with assistive technologies.

Resources that are interoperable with AT should be selected whenever
possible.  Interoperability is indicated by compliance with WCAG 2.0
checkpoints: 1.1.1, 1.3.1, 1.3.2, 2.4.4, 3.1.1, 3.1.2, 3.3.2, 4.1.1 and
4.1.2.The specific details of the AT are normally provided by a user agent
or the operating system.  The example of ‘atInteroperable=true’ expresses
this statement: “resources that are interoperable with AT should be
selected whenever possible”.



In our extended model we refined this for more detail in terms of
AccessibilityAPI as a property which contained an enumerated list that
included AndroidAccessibility, WAI-ARIAv1, MSAA, and so on.



To your point, it would be cleaner to state what web technologies were
needed to support interoperability regardless of what it is used to
support.



We could then refine that to say

Rich Schwerdtfeger



From: "TV. Raman" <raman@google.com>
To: Jason White <jason@jasonjgw.net>, public-indie-ui
            <public-indie-ui@w3.org>,
Date: 06/05/2013 10:18 AM
Subject: User Contexts: identifying assistive technologies



1+ on what Jason says -- to see how this can go badly downhill,
we only have to see how the user-agent string over time has been
abused --- I dread the day where as the asymptotic convergence of
the process that Jason fears, we end up in a situation where the
string identifying the user's assistive tech ends up enumerating
all the AT-names that have been deployed over time.

We might be better off exposing what parts of the Web Access
standards stack the user's AT  is depending on --- e.g. ARIA-1.0,
Indie-UI-Events etc.
--

--


On 5/31/13, Jason White <jason@jasonjgw.net> wrote:
> I'm on record as expressing doubts about whether User Contexts should
allow
> active assistive technologies to be disclosed, primarily for the reason
> that
> this could harm interoperability and standards-conformance by encouraging
> Web
> application authors to write to the implementation rather than to the
> specifications and to introduce AT-specific hacks that work around bugs.
> This
> practice reduces the incentive for AT developers to fix bugs or to
achieve
> greater interoperability, and thus could be bad in the long run even if
it
> assists users in the short term.
>
> Nevertheless, if we are going to disclose assistive technologies, as was
> pointed out to me off-list in response to my requirements-gathering
> proposal,
> the current requirements and spec are inadequate: they cover only screen
> readers and allow only one name and version to be retrieved, whereas
there
> could be several independent assistive technologies (screen reader,
screen
> magnifier, etc.) active on a user's system simultaneously.
>
> Proposal
>
> dictionary assistiveTechnology {
>   DOMString name;
>   DOMString? version;
> };
> then return a sequence or array of the above.
>
>
>