See also: IRC log
<joanie> agenda: this
<joanie> agenda: be done
<scribe> scribenick: tzviya
zakim take up next item
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
<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
<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
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/MS/MC/ Succeeded: s/the name/the name of the deliverable from ¨User Context¨ to ¨Personalization Semantics¨/ Succeeded: s/this will be/this spec. will be/ Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Present: Joanmarie_Diggs janina tzviya Rich_Schwerdtfeger MichielBijl jkva MichaelC matt_king Stefan Found ScribeNick: tzviya Found Scribe: Rich Inferring ScribeNick: Rich Found Scribe: Lisa Inferring ScribeNick: lisa Found Scribe: Rich Inferring ScribeNick: Rich Found Scribe: Rich Inferring ScribeNick: Rich Scribes: Rich, Lisa ScribeNicks: tzviya, Rich, lisa Found Date: 06 Jul 2017 Guessing minutes URL: http://www.w3.org/2017/07/06-aria-minutes.html People with action items:[End of scribe.perl diagnostic output]