Accessible Platform Architectures Working Group Teleconference -- 10 Aug 2016

<scribe> scribe: joanie

preview agenda with items from two minutes

JS: The agenda is a bit different today because we have others on the call.
... We still don't have everyone present we need.
... We want to talk about TPAC, details-summary, note and noteref.
... We have planning around web components, both APA and ARIA perspectives.
... Also, after last week's APA call, we also had some concerns related to EME.
... Thus the top of our agenda is weighted with "meaty" topics.
... Tweaks, changes, additions, other topics?

SM: At the PAUR meeting last week, you asked me to propose wording for security.

JS: Can we take that up under other business?

SM: Sure.

JS: Any news?

<MichaelC> Draft Web Platform Charter

MC: The Web Platform working group is working on a new charter (link above).
... It includes HTML 5.2, HTML Accessibility mappings (question: should they be joint or not?).
... It's a charter with a huge number of deliverables.
... Do we have any comments at the charter level?
... I think we should review it.

JS: I agree.
... One year charter or three year?

MC: Looks like one-and-a-half-year charter.

JS: Any other news?

TPAC Planning -- Details Discovery; Note & NoteRef; Web Components

JS: Given who's here, Shane let's start with note and noteref.

SM: I don't know that much has changed recently.
... We have skeletal spec which talks about note, noteref, and note group.
... There's a web IDL bit in there.
... It's ready to be discussed heavily or discarded.
... I think this means the DPub folks.
... We had a meeting.
... We discussed custom elements, etc.
... Other than that, we didn't do much more than suggest discussing further at TPAC (or decide to stop).

JS: So we'd be asking for time with Web Components?

SM: I think so. I'd like to get all the right groups in the room.

JS: I think it might be useful if DPub and APA were in the same place before we go to Web Components.
... Tzviya and George?

GK: Noteref is an ID and attribute traditional seen in publishing as a superscripted number pointing to a footnote.
... It's pretty fundamental in all types of publishing.

<ShaneM> http://spec-ops.github.io/html-note/index.html

GK: It's been used and standardized in various standards since 1999.

<ShaneM> ISO Z3998 ?

<janina> Z39.86 is the NISO / DAISY

GK: They are both DAISY standards.
... The newer one, where we define an XML mechanism for publishing.

<janina> Newer is Z3998

GK: It's of course used in EPUB as well.
... So long history.

JS: So the goal is to get HTML to pick this up, I suppose.

GK: I would hope so.

SM: Léonie and I have discussed this recently: How does something new become part of HTML?
... There's an incubator process.
... But the only way it makes it in HTML is if the browser vendors support it.

Tzviya: I completely agree with what George said.
... We have this in DPub ARIA.
... The biggest concern from Web Components is support for Web Components.
... That is going to make it difficult to get anyone in the publishing industry to support it.

JS: Seems to me, we'd rather get it added to HTML instead.

Tzviay: That would be wonderful!

JS: I think we should start from that. We can accept Web Components if we must. But it's fundamental to publishing.

Tzviya: Yes, but I think it's fundamental to everything.
... Lots and lots of sites have footnotes.

JS: It's not supported well.

<Zakim> ShaneM, you wanted to talk about the spec

Tzviya: Regarding TPAC, we already have 10 meetings scheduled, so let's add it quickly.

SM: I put a link in for the draft spec.
... Tzviya is correct that custom elements are not very well supported.
... It's in Chrome, and maybe one day will be in Edge, and there's support in Firefox if you enable it.
... I don't think it will be added to Safari, however.
... If you look at the drafty spec, you'll not see anything in there that's terribly complicated.
... At least not in the current draft. That might change....

JS: Proof-of-concept is important.
... And we'll want to bring this up in the context of HTML 5.2.

JF: Is this in any way related to the web annotations work?

SM: They have nothing to do with one another.

JS: It's the choir only if we want to talk about extended description.
... I'm not sure why Léonie is not here. We have her on tap for next week to talk about custom components.
... Rich, I know you're having trouble trying to schedule that.
... I will send email to Léonie.
... I'm sorry to have to ask people to come here twice.
... Tzviya and George, if you can join us next week....
... One comment, people who rely upon other ATs (like Sticky Keys) won't know about extended descriptions.
... Just because an AT is not controlling the user interaction does not mean users won't benefit from extended descriptions.
... This is relevant to why we need this added to HTML.
... I propose we take it up again next week.
... Any other TPAC topics?

EME CR Testing

JS: Last week, I indicated I thought we were fine with EME going to CR.
... But since then, more issues were raised.
... Including some raised by EFF.
... We discussed it over the next few days.
... We again think we're ok with the spec going to CR, but we need to be sure what's in the spec is tested.
... The spec states that the media is best left unencrypted. However, if they are encrypted, it needs to be in the same container with the same encryption method.
... That's a MUST that needs to be tested.
... Some issues are related to color changes for users; also individuals with hearing impairments.
... I presume we'll have tests for these requirements before the spec moves to PR.
... The time data is not encrypted in any case, is that correct?

JF: Yes. And as a matter of fact, we had provided this comment.
... The response we got back from Paul was to put it in github.
... And I may have dropped the ball here.
... The recommendation should be in the spec that the time data should be unencrypted; if it's not, include it in the media wrapper.
... If it's in the spec, then we're good to go.

JS: Please look at 8.5.1 in the spec.
... I think it says that regardless it is not to be encrypted.
... They specifically mention seeking.

<JF> ACTION on JF to review EME 8.5.1 for next week

<trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/WAI/APA/track/users>.

JS: And for seeking, I think you do want that data.

<JF> ACTION JF to review EME 8.5.1 for next week

<trackbot> Created ACTION-2080 - Review eme 8.5.1 for next week [on John Foliot - due 2016-08-17].

JS: I think we agree that it's important, and that we want it unencrypted.

JF: I assigned myself an action and will have it for next week.

JS: Or drop an email on the list.
... And we'll follow up with Philippe.
... Though my reading of the spec is that it's covered.

<MichaelC> associate action-2080 with product-8

<trackbot> action-2080 (Review eme 8.5.1 for next week) associated with product-8.

Actions Checkin (Specs) https://www.w3.org/WAI/APA/track/products/8

MC: action-2073 on Janina

JS: Not yet done.
... All of mine are not yet done due to EME.

action-2053

<trackbot> action-2053 -- Shane McCarron to Review https://www.w3.org/tr/webauthn/ web authentication: a web api for accessing scoped credentials -- due 2016-08-10 -- OPEN

<trackbot> http://www.w3.org/WAI/APA/track/actions/2053

MC: action-2053 on Shane.

SM: I thought I did this.

MC: If so, the action isn't updated.

SM: Oh, this is the any-other-business topic.
... Though I did put a comment in the action.

MC: In the future, setting status to "pending review" is helpful.

<MichaelC> close action-2053

<trackbot> Closed action-2053.

action-2014

<trackbot> action-2014 -- Fred Esch to Review micropub https://www.w3.org/tr/micropub/ -- due 2016-07-06 -- PENDINGREVIEW

<trackbot> http://www.w3.org/WAI/APA/track/actions/2014

MC: action-2014 is in pending review. Should this be closed?

FE: Not unless we said we'd do it in six months.

MC: I commented on July 6th.

FE: Does the action have anything in it?

MC: The last comment is me pointing to the wiki showing that we're still working on it.

<MichaelC> close action-2014

<trackbot> Closed action-2014.

MC: I think this means action-2014 can be closed. And I should have just done that before.

action-2016

<trackbot> action-2016 -- Michiel Bijl to Review clipboard api and events http://www.w3.org/tr/clipboard-apis/ -- due 2016-03-16 -- CLOSED

<trackbot> http://www.w3.org/WAI/APA/track/actions/2016

action-2056

<trackbot> action-2056 -- Fred Esch to Review css properties and values api level 1 https://www.w3.org/tr/css-properties-values-api-1/ -- due 2016-06-29 -- PENDINGREVIEW

<trackbot> http://www.w3.org/WAI/APA/track/actions/2056

<MichaelC> close action-2056

<trackbot> Closed action-2056.

MC: I think we can close action-2056.

action-2067

<trackbot> action-2067 -- Janina Sajka to Draft comment on https://www.w3.org/tr/css-color-4/ css color module level 4 requesting a11y impacts section particularly with transparency and impacts on color contrast measurement -- due 2016-07-13 -- PENDINGREVIEW

<trackbot> http://www.w3.org/WAI/APA/track/actions/2067

JS: on action-2067, the review is done.

<MichaelC> close action-2067

<trackbot> Closed action-2067.

JS: We have a response from Tab Atkins which we need to respond to still.

new on TR http://www.w3.org/TR/tr-status-drafts.html

MC: There isn't anything really new of note.

<MichaelC> Web App Manifest

MC: But there are two specs, one is web app manifest (link above).
... It's just had some churn. They're obvious still working on it.
... We received a reply from them on accessibility fixes. We need to get back to them.

JS: Is there an issue?

MC: The issue was around descriptions, I think.
... The wiki says some may be resolved by the TR design.
... The number of places where the color contrast is not sufficient... Missing longdesc for some images... Unlabeled checkboxes.
... So we need to re-review. And if the problems persist, give them some additional/actionable information.

JS: Who reviewed this?

MC: James Nurthen, last December. We sent comments in January.
... They replied in January asking for more information.

JS: They had an exchange with Charles.

MC: They said splash screens were not an issue.
... They provided a longdesc, though I think we had an issue with it.
... And they said the rest was due to spec generation.

JS: I'm not inclined to drop it.
... We should follow up with them, explaining why what they have done doesn't work.

MC: I think they believe they've addressed the issues, and that the rest are ReSpec issues.
... It could be that everything is ok now, but it could be that it's not.

JS: I can look at pieces of it, but not all of it.

MC: Since it's mostly editorial, I guess I can.

<MichaelC> ACTION: cooper to see if web app manifest comments are dealt with https://www.w3.org/WAI/APA/wiki/Web_App_Manifest [recorded in http://www.w3.org/2016/08/10-apa-minutes.html#action01]

<trackbot> Created ACTION-2081 - See if web app manifest comments are dealt with https://www.w3.org/wai/apa/wiki/web_app_manifest [on Michael Cooper - due 2016-08-17].

<MichaelC> associate action-2081 with product-8

<trackbot> action-2081 (See if web app manifest comments are dealt with https://www.w3.org/wai/apa/wiki/web_app_manifest) associated with product-8.

MC: (Creates action for this work)

<MichaelC> UI Events

MC: Next on I wanted to ping on is UI Events (link above)
... I saw it churn.
... The last action was Cynthia sending an email to the group.
... I don't see any response from them.
... So they've issued a new draft without addressing our concerns. Which isn't necessarily a problem, but....

JS: My suggestion is that we ping them once Cynthia is back.

MC: We delegated this to Cynthia before we realized we should use the CfC process.

JS: Let's bring it back up in two weeks.

Other Business

JS: Two items. Shane first. Comment on Web Payments that we want to run a CfC on.
... I think it's good, but we want to make it less hand wavy.
... Because it's all API, we didn't find anything specific about accessibility.
... But I would like us to be standard about messaging.

<ShaneM> The proposed language is This specification has no defined user interface. Consequently, there are no specific accessibility requirements on implementations. However, to the extent that an implementation provides user interactions to support this specification, the implementation must ensure that the interface is exposed to the platform accessibility API. Moreover, implementors should take into consideration

<ShaneM> the needs of their users with varying abilities when designing solutions that implement this specification. For example, the use of biometric authentication techniques should be varied enough to allow for people with widely differing physical abilities.

SM: I pasted the proposed text (above).
... Does it make sense? Sure. I particularly like the WCAG reference.
... This was meant to be quite generic.
... We'd have to customize it for any spec where we want it included.

JS: I'm still nervous about saying "no impact."
... We didn't find any impact, but it is possible that there is some.
... I'm still wondering if timeout is an issue.
... Keep renewing the timeout if the user is doing something on screen.

JF: Or warn the user.

SM: The API doesn't have any concept of timeout.

Katie: That's in a different layer.

SM: That's a good point.

JS: That's one we know is a common issue. We need to know it's going to be solved in the right place.
... So that the devices can just exchange this without having to throw up a warning that the user has to deal with.

Katie: That could be a note, kind of like is done with the biometric options.
... In general. And it would be for those implementing the API, creating a UI.
... Because I'm not sure that at this level they can do anything about it with any impact.

JS: If the device, say VoiceOver or TalkBack, if they have an API to attach to, the fact that you're swiping around but haven't pressed submit would cause the timeout to renew because it's clear you're interacting with the interface.
... And that goes for desktop browser interactions as well.
... And I'm a little bit sensitive to this. I'm too slow with certain interfaces.

SM: That's a horrible design.

<ShaneM> For example, if a user interface has an inherent timeout built into a transaction, that timeout should not trigger if the user is actively interacting with the system.

JD: Quick note that the user agent might not know about AT-based interactions.

SM: I pasted more text into the channel. (Reads it).
... Is that what you had in mind?

JF: Either that or a warning dialog.
... You see that on banking sites, for instance.

Katie: How can the API specifically do anything about it?

SM: We're not talking about the AT.

JS: So maybe Shane's statement is the best we can do.

Katie: I think we have good examples for implementations.

<ShaneM> Get WCAG reference in there too

Katie: I think we should have a statement that implementations SHOULD ensure the UI for interacting with the API is accessible.

JS: We're sort of having a Web Payments submeeting during the APA meeting.
... Let me ask the generic question: Does the group think we need to hear the final version before CfC?
... This is a process question, and for people here who are not members of the sub team.
... Do we need to bring it back here before CfC?
... I'm not hearing anyone speak up. So if/when the Payments subteam is satisfied, we can move to CfC.

SM: I'll make the changes.

Katie: Are we going to talk about PAUR?
... I posted about the PAUR asking for comments and use cases.
... There were also several people who wanted to join.
... There are three people.

JS: For anyone who is a member, they can ask their ACRep.

Katie: I said that, but it would be great if you could reply.
... The other two, one is a member one is not.

(Group discusses some specific individuals who should join if possible.)

JS: Tab Atkins said, they referred to WCAG in the spec.
... If it's not as thorough as the statement we suggested, should we reply that we want the statement added.

<MichaelC> https://www.w3.org/TR/css-color-4/#notes

CSS Color Spec

MC: (Reads from spec at above link)
... That is good, but I agree we want to add a statement about contrast.
... Combined with what they have now, into an accessibility-impact statement.

Accessible Platform Architectures Working Group Teleconference

10 Aug 2016

Attendees

Contents