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

​Hi David,

I think you may have missed the core of my idea... a manifest file is an
additional "web resource" that could live at either the page or site-wide
level, and it is a linked file/document that provides information about the
content. It would not necessarily be rendered on screen (although it
potentially could), but rather I envision it as an author-created resource
that could then be a means of providing personalization information and
resources.

In the Web-Apps Manifest proposal <https://www.w3.org/TR/appmanifest/>
(previously referenced by Alastair as well as myself)​, it states:

This specification defines a JSON-based manifest file that provides
developers with a *centralized place* to put metadata associated with a web
application. This *metadata includes, but is not limited to*, the web
application's name, links to icons, as well as the preferred URL to open
when a user launches the web application.


Meanwhile, DPUB have stated:

manifest refers to 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.

As such, this has *nothing* to do with the definition of web page, nor for
that matter does it suggest that the manifest file would be a web page (any
more than a WebVTT caption file is a "web page").

(Using the highlighted terms above, it would potentially be a *centralized*
JSON file that had alternate *rendering* information provided - where
alternate rendering = personalization)


In terms of whether or not this would be part of WCAG 2.1 - likely not, but
it *MAY* be something we should be looking at for Silver, as it strikes me
as an excellent opportunity to address some of the current issues we are
grappling with around some of the COGA and LV Use-Cases.

For example, a manifest file could provide a list of possible (multiple)
style sheets that could then be exposed via the user-agent for end-user
choice. It could also be the resource that links a "common words list" to a
site (complete with potential glossary definitions) - or conversely, a list
of "uncommon words" and definitions that could be referenced or adapted to
meet COGA needs.

Those are just two quick ideas off the top of my head, but at the end of
the day the manifest file would be the file that describes "things" about
the web resource, including important 'meta' "things" related to
accessibility and personalization.

As Leonard Rosenthol noted, there is the potential for some collaboration
here that we should be mindful of, and if the Web-Apps manifest (a product
of the Web Apps
​ ​
WG) is open to having their draft web-apps manifest *ALSO* be the home for
meta-personalization data
​ to improve accessibility​
then I see the potential of stronger and faster take-up throughout the
wider development community
​, moving the ball forward sooner and more robustly, as we then piggy-back
onto existing efforts, rather than try to create a whole new thing.​

JF

On Wed, May 3, 2017 at 11:09 AM, David MacDonald <david100@sympatico.ca>
wrote:

> I think Manifest is a good term and a useful concept... I think the
> "manifest" part of it translates fairly accurately to part of our
> definition of a web page, which is defined as
>
> "... plus any other resources that are used in the rendering or intended
> to be rendered together with it by a user agent
> <https://www.w3.org/TR/WCAG20/#useragentdef>"
>
> Manifest is elegant and I like it, but I don't think it adds anything to
> our definition of web page... except that in a future version (silver???)
> we may want to drop the URI bit and go with Manifest file. Perhaps it could
> find its way into an SC???
>
> However, I don't think for 2.1 we want to swap out "web page" for
> "manifest file". I think it would be too jarring for a dot release. I'm
> glad to hear about it though and think we should keep it on our radar for
> future discussions.
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-4902>
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
> On Wed, May 3, 2017 at 11:50 AM, John Foliot <john.foliot@deque.com>
> wrote:
>
>> 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
>>
>> Advancing the mission of digital accessibility and inclusion
>>
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion