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

We should explore it now!(We have a proposal for 2.1)



All the best

Lisa Seeman

LinkedIn, Twitter





---- On Wed, 03 May 2017 21:32:49 +0300  Siegman<tsiegman@wiley.com> wrote ---- 

    If we can sync up with WebApps, so much the better.
  
 John and David, I would love to explore this further. I think we may discover that several of us are on the same page with our goals of personalization. If we are addressing rendering, we should also consider CSS implications. This is shaping up to be a fun project! Is this something you’d like to explore now or later on in the life of Silver?
  
 Tzviya
  
  Tzviya Siegman
 Information Standards Lead
 Wiley
 201-748-6884
 tsiegman@wiley.com 
 
  
   From: Avneesh Singh [mailto:avneesh.sg@gmail.com] 
 Sent: Wednesday, May 03, 2017 2:11 PM
 To: John Foliot; David MacDonald
 Cc: public-cognitive-a11y-tf; public-low-vision-a11y-tf; WCAG; W3C WAI Accessible Platform Architectures; public-rqtf@w3.org; DPUB mailing list
 Subject: Re: Another way forward? (Just an idea for discussion)
 
 
  
    In EPUB 3 based specs, manifest contains the metadata including “accessibility metadata” and list of resources.
 
  It is an essential file in EPUB 3 based standards.
 
   
 
  In W3C we yet do not know what shape will manifest file take, but if the common concept can be used in WCAG and publishing, it would be a good approach.
 
   
 
  With regards
 
  Avneesh
 
     
 
   From: John Foliot 
 
  Sent: Wednesday, May 3, 2017 23:00
 
  To: David MacDonald 
 
  Cc: public-cognitive-a11y-tf ; public-low-vision-a11y-tf ; WCAG ; W3C WAI Accessible Platform Architectures ;  public-rqtf@w3.org ; DPUB mailing list 
 
  Subject: 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 (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"
 
   
 
  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
  
 CanAdapt Solutions Inc.
 Tel:  613.235.4902
 LinkedIn 
 
 twitter.com/davidmacd
 GitHub
 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
 
 
 
 
 
 
 
     
 
  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