W3C home > Mailing lists > Public > public-apa@w3.org > May 2017

Re: Another way forward? (Just an idea for discussion)

From: Alastair Campbell <acampbell@nomensa.com>
Date: Wed, 3 May 2017 16:10:55 +0000
To: John Foliot <john.foliot@deque.com>, public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>, public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
CC: WCAG <w3c-wai-gl@w3.org>, W3C WAI Accessible Platform Architectures <public-apa@w3.org>, "public-rqtf@w3.org" <public-rqtf@w3.org>, "DPUB mailing list" <public-digipub-ig@w3.org>
Message-ID: <B61A95FF-E1D7-4B26-9326-27116E0944CB@nomensa.com>
Hi John,

I think it’s a good idea, and note that there is a similar thing for web apps:
https://developer.mozilla.org/en-US/docs/Web/Manifest


Conceptually, it feels like the big step is defining (more) what the personalisation attributes are and how websites could enable them.

With that in place, a website could use a manifest (or equivalent) to say: “here is what we provide”, and then the user-agent can automatically apply them without the user needing to manually apply their personalisations.

To get the whole thing off the ground, I think it would help to define an MVP and roadmap of personalisation options. Trying to do everything in one go will make it too big. If we could cherry pick attributes from across disabilities that provide the best effort-reward ratio as version 1, then build from there I think it would be smoother.

However, the first task is that categorisation effort.

Cheers,

-Alastair

From: John Foliot <john.foliot@deque.com>


Greetings all,

As part of an APA task I was assigned, I recently reviewed another W3C Working Draft ("Web Publications Use Cases and Requirements - https://www.w3.org/TR/pwp-ucr/) which introduces a proposed concept of a Manifest file, defined there as:

"...an abstract means to contain information necessary to the proper management, rendering, and so on, of a publication. This is opposed to metadata that contains information on the content of the publication like author, publication date, and so on. The precise format of how such a manifest is stored is not considered in this document."

I began to wonder aloud if using a similar mechanism (up to, and including piggy-backing on the Digital Publishing's IG concept of 'manifest' above) might not be a more efficient and economical way of capturing and conveying personalization options at a site-wide level (as opposed to the "page" or single-screen level). I could envision this addressing concerns from both the COGA and LV Task Forces in a fashion that scales efficiently for developers.

While I don't have a clear vision of how all of this might be accomplished today, it strikes me as well that working in concert with the Digital Publishing Group on this piece of the larger puzzle could be quite fruitful.

Please note that I am not at this time suggesting we abandon efforts produced to date, but I am suggesting that we may want to step back a bit and ingest the idea of a manifest file as part of our efforts, as clearly other groups within the W3C are using "manifests" (and/or are proposing to do so). See also: https://www.w3.org/TR/appmanifest/

Thus, I open this for discussion only - but off the top I think there is some real merit in thinking about this more.

JF
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion
Received on Wednesday, 3 May 2017 16:12:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:26 UTC