) 17:14:12 don´t want such elements abused and get away with it with roledescription 17:14:37 could lead to different results in different platforms 17:15:05 do we trust authors to recognize what is truly semantically meaningless? 17:15:19 jc: generic role would help 17:15:22 propose for 1.2 17:15:47 that would define which elements have that as their implicit semantic 17:15:53 providing a better definition for our restriction 17:16:25 if that´s the solution, we might address the issue along with that in 1.2 17:16:36 but the current wording creates a disallowance now 17:16:44 I´d rather soften the wording now and fix later 17:17:34 jd: the whole reason for that restriction is to avoid misuse on generic roles 17:17:39 so don´t think we should take out 17:18:03 could imagine softening, but didn´t get consensus in last discussion 17:18:24 led to proposal for ¨interactive element¨ but gather JC not liking that 17:18:40 jc:
 is example of one that doesn´t count as interactive element
17:18:48  q+
17:19:04  jg: why not use role=region?
17:19:10  with aria-label?
17:19:20  jc: limits future browser handling
17:19:50  right now not many UAs expose CSS 3 speech, but later they may
17:20:04  q+
17:20:15  how they render speech could depend on the role
17:20:37  q+ Bryan
17:20:42  q?
17:20:47  ack s
17:21:13  ss: we have role superposition cases, e.g., columnheaders that are clickable so also button
17:21:31  might roledescription indicate the dual role?
17:21:35  make it interactive?
17:21:51  jd: doesn´t relate to interactive
17:22:54  ss: would keyboard handling be added to the role description?
17:22:58  jd: that´s a tangent
17:23:06  q-
17:23:10  q?
17:23:26  ack b
17:23:51  q+ to say, what if we changed the implementor requirement to UAs SHOULD NOT expose this on elements determined to be generic, such as div/span.
17:23:52  bg: for me not a problem to use roledescription on element without role
17:23:58  bigger problem to use on element with explicit role
17:24:11  could cause UAs to do different things
17:24:58  ok to add description info to generic elements
17:25:11  unless they are used in way that implies a role
17:25:16  but can´t stop authors from doing that
17:25:41  q?
17:25:45  ack j
17:25:45  jcraig, you wanted to say, what if we changed the implementor requirement to UAs SHOULD NOT expose this on elements determined to be generic, such as div/span.
17:26:18  jc: ATs try to do right thing for users, including correcting for author mistakes
17:26:38  but it can be ambiguous whether something is an author mistake
17:27:20  to be on safe side, could speak both native role and roledescription, though that could be redundant
17:27:52  there are author mistakes that cause huge problems, such as marking entire page as hidden
17:28:13  or excessive verbosity in live region
17:28:43  yet we wouldn´t remove those features from ARIA
17:28:53  because used correctly they are valuable
17:28:58  q+ To make counter proposal: User agents MUST NOT expose the aria-roledescription if ... the element to which aria-roledescription is applied is a div, span, or equivalent host language element which lacks a valid WAI-ARIA role.
17:28:59  I think this is like that
17:29:20  ok to correct for *obvious* mistakes
17:29:46  maybe say UA should not expose on elements determined to be generic
17:29:55  allowing proprietary determination of what´s generic
17:30:25  ack me
17:30:25  joanie, you wanted to make counter proposal: User agents MUST NOT expose the aria-roledescription if ... the element to which aria-roledescription is applied is a div, span, or
17:30:28  ... equivalent host language element which lacks a valid WAI-ARIA role.
17:30:35  otherwise, leave with interactive wording for now, but don´t close the issue, come back to it in 1.2
17:30:46  jd: uncomfortable with SHOULD
17:31:18  q+
17:31:28  above wording to specify
17:31:54  jc: yeah, specific to HTML but basically works
17:33:37  mc: avoid getting specific to HTML, use div and span as ¨for example¨
17:33:57  jc: JD proposal works for me
17:34:07  jd: will implement in a branch of your branch
17:35:33  zakim, next item
17:35:33  I see a speaker queue remaining and respectfully decline to close this agendum, MichaelC
17:35:36  q?
17:35:37  ack me
17:35:40  zakim, next item
17:35:40  agendum 2. "Any reason we shouldn't make aria-expanded supported on menuitem?" taken up [from joanie]
17:35:49  https://github.com/w3c/aria/issues/454
17:36:25  jd: since we plan to re-enter CR, was looking for things we might have overlooked that we should fix
17:36:53  the text is clear aria-expanded is meant to be supported on menuitem, it´s just not specified in the property list
17:36:59  it´s already widely implemented
17:37:49  bg: would like that fix, make sure testers don´t flag as an issue
17:38:13  jd: objections?
17:38:29  ss: what about subroles of menuitem?
17:39:15  bg: not implemented on those
17:39:43  jg: APG also using in examples
17:40:46  mc: to avoid inheriting, would have to change taxonomy
17:40:52  bg: not a problem to inherit IMO
17:42:28  mc: we might care about the taxonomy impact, even though it´s academic
17:42:43  jd: there are other examples where something weird inherits, we lived with it
17:43:13  mc: probably better to inherit something useless than not inherit something needed
17:43:13  zakim, next item
17:43:13  agendum 3. "Proposed normative changes related to aria-errormessage" taken up [from joanie]
17:43:20  https://github.com/w3c/aria/issues/587
17:43:28  https://github.com/w3c/aria/pull/589
17:43:49  jd: we discussed last week
17:44:02  I started playing around with implementation
17:44:22  filed issue, pull request, incorporated a couple rounds of feedback
17:45:11  a subtlety uncovered is because of how aria-invalid works, need to change ¨true¨ to ¨not false¨
17:46:03  even if we don´t put in this change, I think UAs will do right thing
17:46:13  but if we re-enter CR, would like to put this in
17:46:29  https://rawgit.com/w3c/aria/issue-587/aria/aria.html#aria-errormessage
17:47:14  zakim, next item
17:47:14  agendum 5. "Identifying anything at-risk" taken up [from joanie]
17:47:36  https://github.com/w3c/aria/issues/588
17:48:05  jd: above are three things I think might be at risk, to add to the at-risk statement upon re-entering CR
17:48:33  they have 2 implementations, but not implemented in the mainstream UAs
17:48:41  MC asked Director for interpretation
17:48:45  have we heard back?
17:49:04  mc: no, but plan to ping in a standing call tomorrow
17:49:23  jd: if we don´t get Director concern, do we even need to re-enter CR?
17:49:27  mc: those were the driving issues?
17:49:33  jd: plus the issue at top of call
17:51:49  mc: think this is mainly our call, rather than Director decision
17:52:06  unless we get a strict response forcing CR re-entry, it´s up to us to decide what´s the optimal strategy
17:52:14  zakim, next item
17:52:14  agendum 6. "Exiting and re-entering CR (quickly) to address aforementioned issues?" taken up [from joanie]
17:52:26  jd: ^
17:52:29  zakim, close this item
17:52:29  agendum 6 closed
17:52:30  I see 1 item remaining on the agenda:
17:52:30  7. ARIA 1.1 "actions / status" check in [from joanie]
17:53:04  zakim, take up item 1
17:53:04  agendum 1. "Creating a subgroup of ARIA WG to work on Personalization" taken up [from joanie]
17:53:20  jongund has joined #aria
17:53:23  scribe: joanie
17:53:37  MC: Lisa wants to make sure there is work happening on personalization semantics.
17:53:46  https://www.w3.org/TR/personalization-semantics-1.0/
17:53:59  MC: This spec was done under the ARIA umbrella, but by the coga task force.
17:54:25  MC: This module contains attributes which can be used to drive personalization.
17:54:34  MC: An example is distracting content.
17:54:50  q+ Noting that Tzviya believes Dpub people would get involved in a Personalization Module subteam;
17:54:51  MC: Your user agent could be used to turn such content off, if you so choose.
17:54:53  http://lists.w3.org/Archives/Public/public-aria/2017Jun/0034.html
17:54:54  q+
17:55:26  MC: Some do not have a proper object content model, which could lead to them being split up, or turned into roles (rather than properties).
17:55:48  MC: We need the ARIA working group to be iterating on these issues so that we can progress to having a usable spec.
17:56:09  MC: For this reason, there is a proposal to create a subgroup/task force of ARIA to do this work.
17:56:28  MC: There's not much point in creating this task force if the only active participant is Lisa.
17:56:43  q+
17:57:00  JS: Tzviya's regrets message for today stated she thought members from DPub would be interested in joining and participating in this group.
17:57:12  ack s
17:57:40  Stefan: There's some potential, but what I don't know is the boundary with ARIA.
17:57:51  Stefan: Will ATs pick this up from the DOM or something else?
17:58:12  Stefan: What discussion has occurred with browser vendors and AT vendors?
17:58:35  MC: Regarding the first question (how these attributes play nicely with ARIA) is a topic for the proposed task force.
17:58:49  MC: It is anticipated that the implementation would be done via browser extension.
17:59:12  MC: For example, if you want to turn of distracting content, I think a browser extension would do it by looking at the DOM.
17:59:30  MC: I'm not aware of a means to expose some of these things via accessibility APIs.
17:59:46  got to another meeting
17:59:48  Stefan: Some of these things would be of use to screen reader users .
18:00:04  JS: This will also work with CSS media queries.
18:00:25  MC: Another of Lisa's important use cases is complex content.
18:00:37  MC: A tool needs to know what bits of information to summarize.
18:00:53  MC: Otherwise, a tool is in danger of including advertising in the summary.
18:01:02  MC: So we need a way to tag these items.
18:01:03  q-
18:01:25  MC: To some extent, those questions should be asked within the group working on this document.
18:01:58  MC: So getting back to the question Joanie asked, is there interest and committment in the group?
18:02:27  JS: Or maybe the question to ask is, is there an objection? Because many people interested could be absent from this call.
18:02:48  MC: With respect to objecting, one cause might be we're busy working on ARIA 1.1.
18:04:14  JD: I agree with busy working on ARIA 1.1. I fall into that camp.
18:04:41  JD: But I also think that those of us buried in ARIA 1.1 are not the same group with expertise in personalization.
18:05:20  MC: (Losing quorum because we're over time) We didn't get any objections, but we don't have enough quorum for a resolution.
18:05:28  JS: I'm not sure if we need to have a CfC for this.
18:05:42  MC: We could draft a work statement.
18:12:12  Zakim, part
18:12:12  leaving.  As of this point the attendees have been Joanmarie_Diggs, Rich_Schwerdtfeger, jongund, janina, jcraig, MichaelC, Stefan
18:12:12  Zakim has left #aria
18:12:21  RRSAgent, make minutes
18:12:21  I have made the request to generate http://www.w3.org/2017/06/22-aria-minutes.html joanie
18:13:09  present- Rich_Schwerdtfeger,
18:13:13  RRSAgent, make minutes
18:13:13  I have made the request to generate http://www.w3.org/2017/06/22-aria-minutes.html joanie
18:13:47  RRSAgent, stop