- From: John Foliot <john.foliot@deque.com>
- Date: Wed, 3 May 2017 12:30:50 -0500
- To: David MacDonald <david100@sympatico.ca>
- Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>, public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>, WCAG <w3c-wai-gl@w3.org>, W3C WAI Accessible Platform Architectures <public-apa@w3.org>, public-rqtf@w3.org, DPUB mailing list <public-digipub-ig@w3.org>
- Message-ID: <CAKdCpxyvdqpO+1D0OhJqtH3aKc3_1J5VEgJ3+9zd6anYM35TDA@mail.gmail.com>
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
Received on Wednesday, 3 May 2017 17:31:27 UTC