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

The idea of a linked but separate document  or block of metadata that acts in the same way as the ONIX accessibility guidelines for ePub really would help if it flagged up accessibility options or the ability to personalise services.  Search engines could also offer targeted sites that comply as they would find the data.  https://idpf.github.io/a11y-guidelines/content/meta/onix.html


There may be a need to map the ontology to include other items, but I can see this as a way forward that could help some of our SCs supporting cognitive disabilities where automatic testing was not possible.

Best wishes
E.A.

Mrs E.A. Draffan
WAIS, ECS , University of Southampton
Mobile +44 (0)7976 289103
http://access.ecs.soton.ac.uk<https://www.outlook.soton.ac.uk/owa/redir.aspx?C=69b1RzNTDwem3wbm4pLRmuYfTLt16YjcghtEpZBsF5Sebx78I2DUCA..&URL=http%3a%2f%2faccess.ecs.soton.ac.uk%2f>
UK AAATE rep http://www.aaate.net/<https://www.outlook.soton.ac.uk/owa/redir.aspx?C=WUwOCw_4FszLSzcUbkoFdDkad8-Q_GrRfPYUJ_ol5l2ebx78I2DUCA..&URL=http%3a%2f%2fwww.aaate.net%2f>

From: Katie Haritos-Shea GMAIL [mailto:ryladog@gmail.com]
Sent: 03 May 2017 19:51
To: 'Siegman, Tzviya - Hoboken' <tsiegman@wiley.com>; 'Avneesh Singh' <avneesh.sg@gmail.com>; 'John Foliot' <john.foliot@deque.com>; '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>
Subject: RE: Another way forward? (Just an idea for discussion)

I also think this overtakes and/or includes the concerns and needs around the proposed Accessibility Metadata SC. So I am happy to let that SC lay low and combine these efforts into one.

​​​​​* katie *

Katie Haritos-Shea
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)

Cell: 703-371-5545 | ryladog@gmail.com<mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile<http://www.linkedin.com/in/katieharitosshea/> | Office: 703-371-5545 | @ryladog<https://twitter.com/Ryladog>

NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.

From: Siegman, Tzviya - Hoboken [mailto:tsiegman@wiley.com]
Sent: Wednesday, May 3, 2017 2:33 PM
To: Avneesh Singh <avneesh.sg@gmail.com<mailto:avneesh.sg@gmail.com>>; John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>; David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>
Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org<mailto:public-cognitive-a11y-tf@w3.org>>; public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org<mailto:public-low-vision-a11y-tf@w3.org>>; WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>; W3C WAI Accessible Platform Architectures <public-apa@w3.org<mailto:public-apa@w3.org>>; public-rqtf@w3.org<mailto:public-rqtf@w3.org>; DPUB mailing list <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: RE: Another way forward? (Just an idea for discussion)

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



CanAdapt Solutions Inc.

Tel:  613.235.4902<tel:(613)%20235-4902>

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://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<mailto: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<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion




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