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

Personalization options for a publication, which may be a whole site or part of a site, is absolutely one of the use cases we envisioned being incorporated into this conceptual manifest. So it does sound like an excellent opportunity for collaboration.

Do you have a link to some of your thinking to date?


From: Alastair Campbell <>
Date: Wednesday, May 3, 2017 at 12:10 PM
To: John Foliot <>, public-cognitive-a11y-tf <>, public-low-vision-a11y-tf <>
Cc: WCAG <>, W3C WAI Accessible Platform Architectures <>, "" <>, DPUB mailing list <>
Subject: Re: Another way forward? (Just an idea for discussion)
Resent-From: <>
Resent-Date: Wednesday, May 3, 2017 at 12:12 PM

Hi John,

I think it’s a good idea, and note that there is a similar thing for web apps:<>

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.



From: John Foliot <>

Greetings all,

As part of an APA task I was assigned, I recently reviewed another W3C Working Draft ("Web Publications Use Cases and Requirements -<>) which introduces a proposed concept of a Manifest file, defined there as:

" 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:<>

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

John Foliot
Principal Accessibility Strategist
Deque Systems Inc.<>

Advancing the mission of digital accessibility and inclusion

Received on Wednesday, 3 May 2017 16:47:39 UTC