Accessible Rich Internet Applications Working Group Teleconference -- 06 Jul 2017

<joanie> agenda: this

<joanie> agenda: be done

<scribe> scribenick: tzviya

zakim take up next item

Creating a subgroup of ARIA WG to work on Personalization

MC: We talked last week about creating a TF for personalization semantics

<MichaelC> https://www.w3.org/WAI/ARIA/task-forces/personalization/work-statement

MC: I have in my queue a few edits to my work statements
... My edits are meant to talk about user context
... In discussion with WAI CC, we identified some pieces of personalization puzzle

<lisa> looks good michael

MC: COGA is part of it, but there is more, such as CSS. This TF would be the best forum for coordination

lisa: Statement looks good. Scope for all disabilities, but personalization for all use cases is probably part of that as well.

JD: What are next steps? PWG is definitely interested

RS: You mentioned that this is beyond scope of ARIA. Say more.

MC: This is out of scope of ARIA, but we are singularly focused on the topic

LS: It is important that we have someone from Publishing

MC: We don't need to recharter, but we are changing the name of the deliverable from ¨User Context¨ to ¨Personalization Semantics¨

JS: We may want to consider not using the word "ARIA" in the title, because it might not all be ARIA

MC: one of the things to clarify is that personalization semantics may be within aria or metadata. This may lead to work in other groups.

JS: Obvious example is experimenting with media queries to handle fonts, background color, etc

RS: There are features in CSS. I don't know where they ended up.
... Does anyone object to forming a TF?
... Who will lead it? Who will participate?

LS: I will lead the task force.

TS: I will not join the TF from PWG, but Avneesh Singh will appoint someone from Publishing Accessibility TF to join

RS: Things are currently lumped under cognitive disabilities, but this reaches many more people.
... Lisa and i presented a white paper about cognitive disabilities and the aging population.

MC: I think we should issue a call for participation
... We need to consider whether this is a joint TF or just ARIA.

JS: I think Judy wants this on the next WAICC call.

RS: We have a rec track deliverable.
... Do CGs have the same RF license?

MC: no, but they can prepare a document to present to WG and then do IP review

RS: I don't think we can do the CG now.

MC: We could do a CG for research and coordinate with WG

TS: in Publishing WG, we have a CG for maintenance and incubation and WG for rec track documents

MC: What is scope of the work? Where do we want to address it?
... Do we agree that we need to work personalization in a larger context?

RS: I think we need to talk to larger world for user context

TS: From a publishing perspective, the assumption is that there will be the ability to adjust font size, bg color, etc
... this is for people with disabilities as well as someone who just likes large fonts

LS: If we open this up like that, maybe it's not just about learning disabilities but learning styles as well

MC: my feeling is that we want to continue develop personalization semantic spec
... We may want to explore user context as well - apart or together
... BEcause we already have rec-track doc, we should move forward and coordinate with other groups as needed
... have in mind that this might spin out into another entity
... CG is obvious place to take over. Coordination group could be another option

<Rich> scribe: Rich

Michiel: I was quite impressed about the personalization presentation at TPAC
... How do we get developers interested in this?

<scribe> scribe: Lisa

rich: compliance was used for aria, but with the delay with 508 there is pushback. we should build the buisness case, inovation approuch
... aging , education market (including higher education) from knowbility smposium, inovation and inclusion is the big interest

wcag.21 scedules are killers,

so go for the opertunity and the complience

not the compliance

but we need to work out how to get out the message.

MS is dealing with brouder includsion (such as the MS stuff)

also think about things like alexia and bots

Michael: also this can be an add on for wcag

<Rich> scribe: Rich

Lisa: There is an add-on in the WCAG space.
... We are trying to get something into 2.1 in either AA or AAA. But, what we are going to manage well is a supplement to WCAG
... We can make it has usable to as many people with disabilities as is possible
... A deliverable of the task force should be the business case.
... Synchronization with IMS and others would be well slotted

<Zakim> MichielBijl, you wanted to ask how we get developer buy in.

Janina: I think it would be smart to look at a bird in the hand vs. more birds in the book.

<Zakim> janina, you wanted to say it's critical to use technology we can control, e.g. plugins

Janina: Nothing in the US before 2020 and I think everyone knows why
... is doing here best to do thi via a Chrome plugin
... leveraging the immediate need by the community should be the first focus
... we should show viability via a plugin
... e.g. e-book readers

Lisa: It seems to me we need the next step - a call for participation
... then we can make as straw poll as to when people can make a call
... We can reach out to digital publishing and Microsoft

<lisa> anytime Michiel :)

janina: we already reached out to digital publishing but we should reach out via the WAI CC call.
... I think I would follow through in WAI CC before the subgroup starts.

michael: I know Judy wants a CC call but I want this on a predictable time frame
... We should refin the work statement and who is interested before the CC call.
... the CC call is in 2 weeks
... We should have a triage of features that require a real engineering effort

Lisa: There are values I would add to.

Michael: What happens in WCAG is a separate discussion.
... I doubt this spec. will be recommended by WCAG 2.1

Lisa: We should kick off the task force next week.

Michael: we should get more dpub involvement first

Lisa: I agree let’s take a look at the work statement

Rich: should we triage features before the task force starts?

Janina: Let’s see who will join this?

<lisa> i will go on mute now

<lisa> :)

<scribe> scribe: Rich

Marking anything as at-risk? (final decision needed)

<joanie> https://github.com/w3c/aria/issues/588

Joanie: only aria-keyshortcuts and aria-details are at risk
... we are not going to get a UIA implementation in time for CR

Rich: I have no objections to aria-details and aria-keyshortcuts being at risk.

Joanie: We can always move things to 1.2 if we don’t make these for CR

Rich: we need to have 2 implementations

michael: Apple could fail to object and also fail to implement so it is the same issue
... If Apple formally objects the director could force us to remove a feature
... We should not mark something at risk because an individual company might object

Rich: Separate implementations on separate browsers

Joanie: we have Chrome support for aria-details.

Michael: I don’t think there is a point in worrying

Joanie: we have aria-keyshortcuts support in Chrome as they wanted it.

Rich: Chrome and Firefox are both IA2

Joanie: we are testing implementability and collecting support.

Rich: so nothing is at risk
... so far

zakeim, takeup item 4

Conclusions regarding aria-errormessage

<joanie> https://rawgit.com/w3c/aria/issue-500/aria/aria.html#aria-roledescription

joanie: I have proposed changes that must show up in the spec. I have buy-in from Google and Mozilla. They could wait until 1.2

<joanie> https://rawgit.com/w3c/aria/issue-587/aria/aria.html#aria-errormessage

joanie: just because the spec. does not have this as a requirement the implementation will be as described.
... we have 2 implementations that reflect the changes to aria-erromessage
... this needs to be a change to the aria spec.

michael: I don’t think it is critical to go back to CR for this.

joanie: Apple and Google agree this needs to be in there

Michael: postponing to 1.2 is something that others might do.

<joanie> https://github.com/w3c/aria/issues/500

<mck> I have to leave for another meeting, but I do think issue 558 should be considered wrt the enter/exit CR decision.

<mck> https://github.com/w3c/aria/issues/558

<mck> We mmay be able to do the same approach; get functional implementations and then let the spec later catch up, but that should be an explicit decision.

joanie: with respect to roledescription we trying to be restrictive but we went too far

<joanie> https://rawgit.com/w3c/aria/issue-500/aria/aria.html#aria-roledescription

joanie: James made that suggestion. but needs to be more prescriptive

<joanie> https://rawgit.com/w3c/aria/issue-500-jd/aria/aria.html#aria-roledescription

joanie: made a comment about using standard controls and others agreed at the last call

<joanie> User agents must not expose the aria-roledescription attribute if the value of aria-roledescription is empty or contains only whitespace characters.

so I am making the “above” proposal

<joanie> User agents must expose the aria-roledescription attribute if a valid value is applied to a host language interactive control.

Rich: how do you determine validity

joanie: it is valid if it isn not empty or has only whitespace characters

<joanie> If aria-roledescription is applied to a host language container element, user agents must not expose aria-roledescription unless the author also defines an explicit WAI-ARIA role value, or the host language has explicitly identified the element as supporting aria-roledescription.

joanie: James said he wants to be able to put a roledescription without a role attribute
... nobody can figure out a host language description of semantically meaninful

<joanie> https://github.com/w3c/aria/commit/0c47c14

<joanie> 10313 is too restrictive. It puts a lot of extra work on the host language specs. E.g. this would be supported on role="main" but not <main> until HTML made a change... This would also not be supported on most SVG elements, where is may be most useful.

Michael: you should post our comments and there was an unsuccessful effort to solicit a response the director would take that into account
... the github issue provides enough documentation
... Are we going back into CR?

Rich: put new roledescription language in but at risk

joanie: branch or master
... ?

michael: I would branch off of master

joanie: should I put this in master knowing we will do a new CR from master
... ?

michael: we can put the feature at risk in the satus section
... I will reference the status

joanie: i will put the error message and the roledescription change in the branch

<joanie> chair Joanmarie_Diggs

<scribe> chair: Joanmarie_Diggs

Accessible Rich Internet Applications Working Group Teleconference

06 Jul 2017

Attendees

Contents

Creating a subgroup of ARIA WG to work on Personalization

Marking anything as at-risk? (final decision needed)

Conclusions regarding aria-errormessage

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output