Accessible Platform Architectures Working Group Teleconference -- 06 Nov 2017

<tink> scribe: tink

CSS meeting prep

Meeting APA TPAC Day 1

JS: Preparation for our meeting with CSS tomorrow.

IP: Need to put together the agenda for tomorrow.
... We should start with introductions.

JS: Yes, names and affiliations.
... Perhaps a more detailed intro from you though.

IP: I'll cover a brief history of the TF too.
... With ARIA in PR now, we might get some more participation, but a call for participation would still be a good idea.
... We need to improve assigning people to reviews.
... So far it's only been me and one other person doing the reviews.
... Need to prioritise what's left.

JS: I think their expectation is that the list will be short.

IP: We have a list of issues they're probably aware of.
... We should go through those open issues and determine what needs to be done.
... Then we should cover how the TF is expected to work with the CSS WG.
... We understand how it works with APA, but it's less clear with regard to CSS WG.
... Three related things:
... Raise things that arise from the meeting with the Publishing people.
... Last year we had good agreement that media Features were a potential solution to some of the Publishing problems.
... There are 12/13 features available I think, but they don't cover all the use cases we have.

<scribe> Meeting: APA TPAC Da1

JS: Yes, there are things the Publishing people are looking for that have a high priority.

IP: Personalisation and Coga is another topic.

JS: Lisa isn't here this week.

<lisa> i am on the phone when needed

<IanPouncey> https://github.com/w3c/css-a11y/issues/14

IP: These minutes talk about Cga as a stakeholder for the CSS Media Queries (should be Features).

s/cga as/Coga as/

JS: We'll want Lisa here when Charles is present.
... To synch between Publishing and Coga.

IP: Final thing is navigation in layout.
... Met with Jihye Hong from LG yesterday.
... She works on their TV platform team.
... They're proposed a CSS spacial navigation module, which is available on WiCG/Github.

<IanPouncey> https://lgewst.github.io/SpatialNavigation/

JS: Do they rely on CSS?

IP: Yes.

<IanPouncey> https://github.com/lgewst/SpatialNavigation

LW: Do we know how/if this relates to the existing spacial navigation properties in CSS?

IP: Don't know, but hope she'll join the CSS WG meeting tomorrow to discuss.
... There is a sugestion this could be included in the AAM docs wen it happens.

<aboxhall> English version: https://github.com/lgeweb/spatial-navigation

JS: What is the expected behaviour?

IP: That's the discussion.

<aboxhall> Explainer, linked from above: https://github.com/lgeweb/spatial-navigation/blob/master/explainer.md

JS: In Sopporo you said that rewriting the DOM was too expensive Matt.

MK: If it becomes too much of a black box and you can't credibly understand what the navigation will be, it's a problem for engineers.

IP: First step is to document what the behaviour should be.

LW: Worth noting that Firefox (before it changed) didn't rewrite the DOm to fix the keyboard disconnect.

MK: Having reading order match navigation order is critical.
... Hybrid touch/keyboard navigation is another context to think about.

JS: When people say "too expensive" I question how much process power we need before it becomes acceptable.

LW: It's a different kind of expensive.

IP: Do we want to take a specific proposal?

JS: I don't think theyll have answers?
... Think we need to develop our own list.

IP: Do we want to try and define now?

JS: Be good to get some ideas on the table.

https://tink.uk/flexbox-the-keyboard-navigation-disconnect/

IP: So where does the problem exist?

JMD: When rendering engines were being developed we weren't thinking about injected content, so now the implementations have to work around that.

<jnurthen> Just monitoring on IRC - but didn't we discuss flexbox tab order issues w/ CSS in Saporro?

<aboxhall> https://www.w3.org/TR/html-aam-1.0/ AAM for HTML

JS: Perhaps we need a CSS AAM?

MK: Screen readers do sometimes take CSS into account, but there is no standardisation.

JMD: Agree we could do with a CSS AAM.

<joanie> The list of CSS-generated content issues which I had sent in the PFWG days is https://lists.w3.org/Archives/Public/public-pfwg/2014Nov/0094.html

<aboxhall> Thanks joanie

MK: Even if you make a sweeping statement that nothing in this CSS module should affect the accessibility layer, browsers respond and it ends up making things work differently in that browser.
... Safari does interesting things with spacing that dont happen in other browsers for example.
... Having expected behaviour/implementation mapped out would help.

IP: Matt, are you suggesting that CSS should not affect the acc tree unless specifically documented otherwise?

MK: Yes, something to that effect.

JC: What about display:none;

MK: We can document the things that could/should/would.

IP: That would require a hefty review I think.

JC: There are a lot of complications.
... Browsers rely on implementation guidance for the rendering tree.
... Correcting 10/15 years of bugs because of the differences between browsers.
... Things like CSS that affect the rendering tree also effect the acc tree as an artefact.
... So a broad "CSS should never affect the acc tree" is likely to be a problem.
... Finding ways to keep the mainstream interface accessible, is the best aproach in the long run.

IP: So it's the exceptions that need to be well documented then I think.

JC: Is navigation eing used broadly?

IP: Yes.
... Content order with models such as Grid is relevant too.

JC: Grid is a good one to tackle on a case by case basis.
... spacial navigation is on the table for that, as long as the spec and implementation can prevent looping.

IP: Yes, it's on the agenda for tomorrow.

MK: Spacial navigation works in software - spreadsheets for example.
... Can also get information like border description, things that are important.

JC: For Grid, having some guidance in the spec makes sense.
... For other things, it's different.
... Layout tables used to be common.
... browsers now have heuristics for correctly identifying data/layout tables.
... I feel a lot of these things come about because people file issues.
... For the finer details in CSS that's ok.
... But for Grid - does Grid affect order, it's bigger and needs speccing.

IP: Good to know, thanks.
... We weren't sure whether the spec or an AAM would be the answer.

JC: In my experience, the CSS WG is open to accessibility solutions as long as the CSSWG is part of the discussion. They will even raise issues with the proposals that A11y people outside the CSSWG have not considered.

LW: That's the best way to have these discussions IMO.

JS: Hence the TF.

<Zakim> joanie, you wanted to mention text formatting and https://github.com/w3c/aria/issues/651

JMD: When people file bugs it gets dealt with.
... We have no docs that describe what should be exposed.

JC: Is that consistent across browsers?

JMD: No idea. Willing to bet Gecko lacks an implementation consistent with the other user agents.

<lisa> i joined the phone

<clapierre> scribe: clapierre

??, publishing a11y discussed last years TPAC using media features for both personalization and publishing.

scribe: , what would be useful, input on what we can talk about

Janina: issues around navigation, what is next. how do we know and based on context. how to start maybe with grids.

James: wrt publishing correct?

Janina: Yes

James: what are specific Media features needed or css.

Ian: there shouldn't be anything right now specific to publishing, but things helpful for
... , existing Media features for publishing but shouldn't be anything major, but get a list of features that would be useful.

Matt: request is situations where controlling where speech / readback of puntuation is really essential to the presentation of the material, but if there is SR set to some/none that omitts punctuation that is essential.

Ian: so is this specific info?

Matt: not only scientific only but ..

Lisa: In Isreal there are direct marks and in arabic there are 6-7 words work it out for context slow readers, the identified essential diatric marks to reach lower reading levels.

Matt: there was a testing situation grammar tests that every single punctuation marks be announced but only in one sentence was the punctatuation for testing.

James: wouldn't a student be able to read char/char a solution here?

Matt: an advance SR would switch to the higher level punctuation. set to all but then you must switch between. Some may not even think to switch the punct. level.

James: a lot of screen reader users if they don't understand a word they can go char/ char to learn the spelling.

Matt: is this a topic which falls in CSS?

Janina: there is CSS SPeech / Braille.

James: css speech has been implemented in WebKit.

George: in my mind visual css presentational items. that could help people with reading and people with learning disabilities different styles for headings. there is a number of htings that could be for personalization based on semantics. Punctuation issue seems to me that there is a break between blind sudents and people who have dyslexia that are not using the AT, but mroe and more are using the REad aloud and punctuation level to have a

more plesant reading experiene, but with DIAGRAMMAR perspective that info can be placed in a details element, that ARIA details that point to HTML details element that could have simplified language, or detailed description and other alternatives like tacktile / 3D etc.

scribe: , if someone always had a flag set to simplify that could help.
... , request for on the fly simplified words that synonmy for complex words would be put in automatically to replace that content. these are what is being asked from publishing.

<lisa> https://w3c.github.io/personalization-semantics/

Lisa: Charles and I work on the personalization TF for aria
... , great implementations simplifications early stage of dimentia may not be able to manage GitHub unless maybe you reduce to the main 3 things then them might be able to use it.
... , Folks with numerical abstractions disabilities, they might need alternatives to text and math. like 85%
... also giving different icons where learning new things but long term memory might be good but learning new icons / symbols are difficult and using instead what is useful
... cases where you want more/less info, feedback text vs. voice.
... , not everyone want to see that, breadcrumbs who get distracted if we put this into the markup and the question is are they visual or not.
... there could be a better way to get at it maybe JSON or other ways.
... publishing
... CAST we made mark things as …
... having these extra types and people can jumps to the bits they need.

George: content vs. user interface in publishing we tend to think of these as two separate things.
... , good HTML is needed… its free if the RS provides it.
... changing the content for what what is needed to read is a content. maybe Topic sentense that a person with learning disabilities could focus on.

Ian: COGA personalization have attributes for simplification low/med/high
... those can be added to the markup displayed or hidden based on Media feature by UA or the device reading level etc.

Janina: isnt there something from the AU? concerning that.

Lisa: we making personalization right now we are focusing on the semantics and the vocabulary we will ahve a way for the developers to access it.

Janina: we do mention this tomorrow that this is an ARIA module but we are getting to CSS in the process

Lisa: what we could have Media Queries, where I can set that I only want Important content and via Media Query, but there might be a better way maybe JavaScript, etc. But you need that page mark

George: could be a whole collection of pages and the modifications would need to carry through the entire publication.

Janina: Medicare and You

Ian: idea is that you would configure UA to you prefer simplified content.

Michael: you could set something that could trigger something

Ian: you could set some preference in your UA.
... , JSON file would take your preferences

Lisa: very early page of things user implementations there could be other ways JSON or JSON with CSS to do this.

Michael: a JSON file could have some preferences that could use Media Queries access to it.
... , we focus on what the UA should know about as a preference. list of what UA would recognise. implementation on how UA gets told about it.

<lisa> early colection is at https://w3c.github.io/personalization-semantics/user-settings

Michael: , CSS WG some of these make clear sense and others dont. refine from our ask list and what will we do to make sense.
... , do we have the full list?

Lisa: the list used in implementation so far, and we are starting to collect them and a11y term a11y features, this is what we know about so far.

Michael: I can't make sense of this but the indyUI but is a dead spec but how can we do this in the next 24 hours to talk with the CSS. the tablle columns are messed up.

Janina: we only have an hour to it. we don't need to give them a list, and we want to give them something … maybe user context might be a way to do that.

<MichaelC> https://w3c.github.io/personalization-semantics/#semanticProperties

Lisa: personalization Use cases simplification and that is where it says what kind of things we are looking for familiar terms that might be more helpful.

Michael: this is too detailed for a quick discussion but a good think to point to.

<MichaelC> https://www.w3.org/TR/indie-ui-context/

Michael: similar level of detail, but is personalization usecases will be easier to go through.
... , pick a few examples that are representative, don't try all of them, don't pick one disability but a representative example.

Ian: user font sizes, colors, user limited font type.. inverted colors (already there MQ?)

Michael: not sure how many map to MQ.

Janina: or via CSS

Michael: this is the simplified content but MQ will jsut be able to know what the user needs via some personalization settings but I am not sure how it will behave past that.

Lisa: simplification and ICON set that people prefer to use.

Michael: thats an outcome what is the need we need from CSS.
... , we want authors support MQ special CSS for icons, special CSS alternatives for math, CSS alternatives for distractions, Non-Literal examples
... , simplified content is an attribute.
... , default css not to display it
... , browser preference to allow for simplified content.
... , at simplified content either display it or whatever else to do to it. otherwise it doesn't show up

Ian: COGA semantics could already be ref. in default CSS.

Michael: but then we wouldn't need MQ

Ian: there can be defaults but also author specific.

Michael: what would browser css do with these properties?

Ian: it would display or hide things.
... this is a big ask. is this something that you want to support. there would be some defaults COGA simplified low for example (is there a simpified default? lisa?)

Lisa: type of button we have assoiated a default if it is critical like Next is important but we don't have a general default.

Michael: we ran into the ext. desc. that all cotent should be shown to the user but that will be a phylosiphy in the CSS, there are a11y to hide some content but not everyone will buy into this and we will run into that if we hide things by default.

Ian: COgA will display different content.. .but on user request.
... there is a JS implmentation

George: we buy into the idea that this information should be hidden but the problem we have is in selection cognatively more difficult to select where simplified version could be first.

Michael: here is the simplified version of this content, but having the longer description and then if there is nothing preventing it from showing the user will get both.
... CSS web platform our workin personalization semantics and UA and we don't know . and for CSS we don't want to make it look like we are asking too much fro CSS.
... , Web platform meeting we will need to talk with them as well.

Ian: I am not pushing one way or another but if COGA and publishing and we should raise it

Michael: best success with CSS and web platform is via use cases and not the "How"
... , this may have interesting issues with UA.

Janina: we are past the hour.
... , we have not exhausted this. 9AM tomorrow we could revisit CSS and personalization and what we say in the CSS meeting in their room. lets table this until 9am tomorrow.
... , we will have a wider discussion with publishing as the last session of the day: Silver and publishing, Lisa you are welcome if you want

<Roy> scribe: Roy

<tink> scribe: Roy

Editing on the web

<tink> LW: For the Inputs Event conversation tomorrow we need to revisit the questions from the previous meeting.

<joanie> https://lists.w3.org/Archives/Public/public-apa/2017Sep/0011.html

<tink> > 1. From an accessibility perspective the following would be valuable:

<tink> > - A notification to ATs that functions like text insertions were completed

<tink> > so that positive reinforcement could be provided to the user.

<tink> > - 2. A programmatic way for alternate input solutions to drive some of the

<tink> > changes would be helpful. For example, an AT might want to insert the text

<tink> > now that this can be done in a device independent way. Some of this may be

<tink> > provided for in UI Automation (Windows platform) but are they provided on

<tink> > others?

LW: we need talk to API people

Joanie: don't know if support by Firefox, screen reader @@

<tink> scribe: tink

JMD: Took a task to look into this.
... Looking at WebKit code, and being more familiar now with the Input Events spec, I'm confident most things cn be exposed.
... Notification of text changes is already handled in software like Libre Office, MS Office etc.
... So the screen readers have had to deal with this already.
... It'll be important to filter out DOM changes from user triggerable input.
... We'll need some way t identify what triggered the change.
... For example, in IA2 I think and definitely in ATK, is suffix system.
... We have object:textchanged:insert objects etc.
... Need to differentiate between computer generated events and user generated events.
... If there is a system suffix we're likely to ignore the event.
... So we might hypothetically want a new feature in the API to identify "editor" or something.
... Not convinced of this yet myself though.
... There are also implementation ways to deal with this.
... I think we might need another AAM.
... It won't be hard, but we need to document the expected behaviours for UA.
... We might need more acc API features for things like history redo/history undo events.
... I don't see that we need anything from the Input Events spec.
... I think we'll find there are things missing in implementations.
... Testing now to find out whether support for editing events is in place in WebCore (WebKit).
... Will test with TinyMCE.
... So short answer is that I don't think we need anything from Input Events.

<aboxhall> Has there been any discussion previously about AT-generated events like accessible increment?

LW: Would encourage the Input Events editors to include a section that indicates that accessibility has been considered, and points to things like the AAM if it happens.

<aboxhall> [may be off topic, apologies if so]

JMD: Wonder if it could be incoroprated into the HTML AAM.

JDM: Thinking for AOM and creating progressbars etc.

<aboxhall> Yes, exactly

<aboxhall> Has there ever been discussion of doing this in HTML proper?

<aboxhall> Making them first class input events like click, keypress etc

LW: Think that would be a conversation to have with the UI Events spec editors.

<aboxhall> Sure. Off topic here then.

<aboxhall> Thanks.

JMD: Screen readers can already issue instructional messages, like swipe right etc.

JDM: If the question is about setting values, like a spin button.
... Theoretically through AT we should be able to increment and decrement them.
... Why that can't be done for ARIA isn't a UA problem, so much as an author problem.

<aboxhall> oh yeah I can head over if you want to talk more about this

AB: Yes, you can change it if it's attached to an HTML element, but not when it's ARIA based.

Autonomous Vehicle A11y Exploratory Overview

<MichaelC> https://www.w3.org/2017/11/06-auto-minutes

A11y Self-Assessment Survey & A11y Impact Statements

<MichaelC> FAST checklist: https://w3c.github.io/apa/fast/checklist

<MichaelC> FAST: https://w3c.github.io/apa/fast/

<MichaelC> Other horizontal reviews: https://www.w3.org/wiki/DocumentReview#Review_Resources

<MichaelC> mc: no real uptake

JS: Think we can use it pre-emptively - with Automotive for example.

<MichaelC> have done a bit of advertising, not much

<joanie> scribe: joanie

MC: Doing that would give us some feedback about usability of the tool.

LW: I suggest a blanket email to the Chairs mailing list to uses this tool as part of their wide review.

MC: When I'm at that point, I am not looking for feedback.

LW: This is something that was done with Security and Privacy.

MC: Those groups have better socialized doing these checks as part of wide review, with the possibility of raising a formal objection.
... Coding work on this had to be set on hold due to WCAG and ARIA.
... Maybe Roy can help with this.

Roy: I can try my best.

JS: I don't think we can expect other groups to use it if we don't do so.

MC: We should use it ourselves first.
... Maybe for some upcoming spec reviews, we should ask the reviewer to use the checklist.

IP: What is the consequence of failing the review, as opposed to not doing the review at all?
... From a Process point of view.

MC: On paper, if a spec lacks an accessibility feature, it's considered not ready for Rec.
... In practice, if the spec is late in the Rec track, we may get some pushback.
... I think this would be most useful at the requirements stage.

JS: Yes.

MC: But it's also useful at other stages to verify those requirements have been met.

IP: Does this tool give good expectation of what the requirements are?
... Or is it possible that you could use the checklist and still fail to address an accessibility requirement?

MC: That's possible, but if the checklist is good that won't happen. But this will need to be addressed iteratively.
... But hopefully using this checklist will ensure they've addressed most issues.

JS: I think it's really good at identifying areas where you want to work with APA because you might have problems.
... You know what you're trying to achieve when you start developing a spec.
... And I think this tool is useful in determining where the rub points might be.
... Rather than at the end of the process, when you're dotting i's and crossing t's.
... Which is different from what Internalization and Privacy do.

MC: But those groups aren't using this as compliance tools.
... So what I'm hearing is let's use this tool ourselves. And making it checkable. And then do another round of marketing.

JD: I'm wondering if we could modify the interface so that not so much information is exposed at once because it can be somewhat overwhelming to me.

MC: I would be tempted to not show the second and third columns at all, but people not familiar with accessibility might not know what the first column (with the checkbox) means without the details and references in the columns to the right.
... But this might be something we can do.

IP: Are there more areas?

MC: If I had more time, I would like to complete the User Needs Analysis.
... User Needs is a section of @@@
... The first section talks about the approach. Let's do some research about the needs we are solving, and what needs are we missing?
... One of the reasons we're doing WCAG 2.1 is because there are user needs which we missed before.

<MichaelC> https://w3c.github.io/apa/fast/

MC: I got quite a ways through this content, but not yet able to work through all the documents referenced.
... The other thing we wanted to talk about in this topic is... It's become an expectation that other specs have privacy and security sections.
... It's been suggested that we want to do something similar with accessbility.
... For instance with CSS colors, we might want to add a statement to the spec that calls out potential accessibility impact.
... We've not yet been able to do this.

JS: I think we should push for it.

MaryJo: Globalization considerations are similar to accessibility when you're doing any kind of development of technology.
... You could miss translating a property in ARIA.

JW: It seems to me that if there are considerations that people implementing the spec need to take into account, they should be alerted to it in the document.
... Also for people using the spec.
... So I think there's a good case in general for doing this.
... But it doesn't seem obvious to me that it applies to every spec, but only to a subset for which it should become standard practice.

JS: If you look at our tracking wiki, you'll find many instances of "no accessibility impace."
... Still, I wonder if we want to pursue this, rather than just point to WCAG.

MC: We really do need to think about who is the primary audience of the spec.
... In many cases it's the user agent implementation.
... So unless a spec is author-oriented, it probably don't make sense to have author-oriented accessibility advice.
... In the case of colors, the advice might be that user agents SHOULD make it possible to override the colors.

JW: One example, with the web authentication spec which I reviewed, one of the consideration is that server-side implementors should be careful about what sorts of devices users should have to provide valid authentication.

MC: That's probably reasonable.

JW: This is not yet addressed by WCAG.
... WCAG doesn't address biometric authentication, whereas the EU and Section 508 do.

MC: Janina and I have had an internal W3C debate about this, but do we have any consensus from the Working Group about what we should do?

<lisa> join the webex

JW: Could APA start asking where it makes sense?

MC: We've tried that, but it hasn't always helped. We have had pushback.
... Sometimes we can talk to them; sometimes they believe that this sort of thing might "pollute" their spec.

JS: We could still elevate it.

JW + JS: We need examples where it makes sense.

<lisa> i can not hear

<maryjom> scribe: maryjom

Publishing Issues Discussion

Avneesh: Want to have an open discussion with the Silver TF to incorporate digital publishing into that standard, instead of having a separate spec.

<lisa> +1

<lisa> (to avneesh)

Avneesh: Another topic to discuss is media overlays and how to incorporate these requirements into the standards as well.

George K: As you publish a digital book, a page number is required so that all users can go to a particular place in the book easily and quickly. It's been in Daisy forever.

<Avneesh> requirements for AG https://github.com/w3c/publ-a11y/wiki/Publishing-issues-for-Silver

Daniel: If a publication is part of a collection of documents. These documents may contain span elements with the epub namespace to create a page break. This provides a place for a user to jump to a particular place.
... There is a page list in EPUB3 which one type of navigation list that EPUB3 has.

Janina: I don't think you have to have a disability to want this.

George K: Today documents add in a virtual page break which is different than dynamic pages where if you increase the font, the number of pages gets increased.

Matt: There is a desire to create a consistent method of marking page breaks that make the page break common to be able to have a common way to access a particular page. We need standardization in this area.

Janina: There is a mainstream case for this, and while it's great we have HTML5, things paginate differently whether you're reading on a laptop vs. a smartphone, etc.

Jason: Regarding pagination, if we take a web publication and print it, the typesetting for the printable format will affect the page breaks. This isn't only an authoring or markup issue
... ...it's also a user agent issue.
... Metadata is an important issue to raise with the Silver Task Force. Even if you don't conform to a WCAG level conformance requirement, you can conform to the EPUB specification.
... It might not be an accessible document. We have to be careful about how you relate the metadata requirements with the accessibility requirements.
... It has to be considered when thinking about conformance and the conformance requirements.

Matt: Having static markers could make a standard pagination, though it might not match the pages as you print the document.

Jason: There could be a unit like paragraph reference mechanisms that could be used instead of page numbers, paragraph numbers, for example.

Janina: The government even uses line numbers.

Avneesh: It is true it isn't just an accessibility issue but a universal one. We'd like to come up with a roadmap.

Lisa: With metadata and conformance, the ability to tag what's being conformed to and what's not being conformed to so you could provide alternative content, like for someone with a learning disability.
... Maybe describe the user needs that are being met in the tagging.

George K: We have the concept of an optimized publication, like braille, or an audio book. It is optimized for certain people, so we can point to the specification that it conforms to.

Jason: There is interest in publishing group, particularly in education, to publish a one-source version of the publication but that if there's users with different user needs there's metadata to customize the publication for them.

clapierre: In EPUB spec there's access modes that you can specify and you can also specify the combination of modes that are needed to consume a sufficient amount of the information in the content.

Jason: Is there a taxonomy that the community consuming these documents to know what to use to find and use these adaptations

Matt: This is where some of the metadata has been developed from in the schema.

George K: There was a discussion today about personalization to modify content based on user preferences.

Janina: We are beginning to make progress in that area.

Avneesh: The schema is recommended as a conformance requirement in WCAG 2.1, but we want a stronger requirement in WCAG Silver.

Shaun: Matt has written up some of the digital publishing requirements for Silver in the wiki. The document can have metadata to say what accessibility modes/content it includes. This would be useful beyond just publishing, but in applications.

Matt: This metadata wasn't designed specifically for publishing, but generally for schema
... It was designed to be cross-industry and not specifically for accessibility.

Jeanne: Why isn't this being specifically required as part of WCAG 2.1?

Jason: It was considered, but some argued it should not be a success criterion. We thought the correct way to describe the requirement for metadata is to put it in the conformance criteria.
... The way that conformance claims are made, machine interpretable conformance claims are optional, and maybe they should be required.

Lisa: Perhaps the metadata being used for accessibility and metadata for cognitive disabilities should be reviewed and see how it can be integrated.
... There's also mental health as another aspect to consider when looking at the metadata. We've been looking into mental health in some new issue papers.

<Zakim> jeanne, you wanted to say that since Silver is not restricted to content, we don't see a problem

Jeanne: We know Silver will apply to more than just content so there shouldn't be a problem incorporating it.

Avneesh: How do we coordinate with APA and Silver?

Janina: The APA WG can push on the HTML spec and will help carry that forward.

Jeanne: We definitely want to work with Digital Publishing, but we aren't there yet. We are doing user research and then prototypes of the structure of Silver.
... We won't be working on actual content until 2018, like a year out.

Shaun: We have a collection of papers and blog points to keep track of issues to cover in Silver. So please continue to add anything you want to make sure is addressed.
... We want to make sure it isn't just single-page web content to things that are multi-page like EPUB publications.

Jason: The way with WCAG currently defines conformance creates issues with the current definitions/use of "web page" and "set of web pages". The use of WCAG for non-web software will help shape the language used for requirements in Silver.

Marisa: Talking on the topic of media overlays in web publications.
... Who uses media overlays? Blind and visually-impaired users, users with cognitive disabilities, and they are used in professional audio books such as children's books.
... Readium uses this technology.

<Avneesh> Requirements for Media Overlays: https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia

Marisa: Audio playback is synchronized with text highlighting. The user can navigate while audio is playing - to the TOC, by page, and finer granularity like paragraph or sentence.
... The user can escape out of complex structures like tables, or customize their reading options. They can change the speed of reading or do time-based navigation.
... EPUB3 introduced Media Overlays using a small subset of SMIL.

Janina: SMIL is dead.

Marisa: We want to move media overlays and have considered other technologies: TTML, WebVTT - which use their own text format. We don't need to duplicate that since we have HTML5.
... Web animations have no syntax. Web annotations looks promising and I've talked to someone recently about it and it seems active.

Janina: I thought web annotations was dead.
... I want to be in the conversation with that group to understand the status of web annotations.
... We tried to have the markup in HTML 5 plus WebVTT to have the functionality of this supported.
... We got everything but transcripts, which died but can be resurrected. One of the things we need to trial is try to make an example demonstrating all of the capabilities we'd like to see.

Daniel: What we are lacking is a replacement for SMIL that sits outside of text, the video, the audio. It isn't like the captioning use case of a video with the separate captioning.
... This is taking two different forms of media and making the text the master.

Marisa: This is why we think web annotations is promising. We can also likely use personalization for media overlays reading options - especially to provide skippability.

<lisa> marisa this looks greatq+

Daniel: I want to have some emphasis on audio-only books. As a reading experience, I don't have to listen to the audio. There's a technical gap in EPUB3 media overlays to retrofit audio books.

Janina: The ability to mark up the text transcript with timing didn't work, and is still a gap we havn't met.

Matt: Web publications metadata could be used potentially - it should be investigated.

Jason: There does need to be a general mechanism as there are non-accessibility use cases that can be useful to think about.

Janina: Part of the MAUER there's a concept called second-screen and that may be a bluetooth headset getting the audio descriptions - not necessarily a real second screen.

Lisa: The vocabulary we're putting together in the ARIA personalization may be a place where the extra information could be added into content and slide into personalization as an additional use case.
... If anyone wants to join the personalization task force, you are welcome to join

Avneesh: What are the next steps?

Daniel: We need to be able to figure out use cases and requirements.

Janina: We can come up with a list. We should look at the transcript specification and see if we can get some implementations to move it forward.

Jason: Will publishing working group be able to push that spec through?

Avneesh: We could have a task force, a smaller group work on that.

David: The Library of Congress has a lot of recordings with timed transcripts.

Marisa: We want to expand to more types of content than what we have so far.

Janina: We've got markup for changes in language.

George K: There's a lot of people wanting to work on music too.

- DRAFT -

Accessible Platform Architectures Working Group Teleconference

06 Nov 2017

Attendees

Contents

CSS meeting prep

Editing on the web

Autonomous Vehicle A11y Exploratory Overview

A11y Self-Assessment Survey & A11y Impact Statements

Publishing Issues Discussion

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output