See also: IRC log
<scribe> scribe: joanie
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?
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?
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.
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.
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.
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
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.
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/power/PAUR/ Succeeded: s/CR process/CfC process/ Succeeded: s/place/layer/ Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Found Scribe: joanie Inferring ScribeNick: joanie Default Present: Janina, Joanmarie_Diggs, LJWatson, ShaneM, fesch, MichaelC, Cyns, Gottfried, Katie_Haritos-Shea, Mary, Mueller Present: Fred_Esch George_Kerscher JF Janina Joanmarie_Diggs Katie_Haritos-Shea MichaelC Rich_Schwerdtfeger ShaneM Tzviya fesch Regrets: Cynthia_Shelly Found Date: 10 Aug 2016 Guessing minutes URL: http://www.w3.org/2016/08/10-apa-minutes.html People with action items: cooper WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]