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.
>
>
>

Received on Wednesday, 5 June 2013 15:12:00 UTC