W3C

- DRAFT -

ARIA WG

21 May 2020

Attendees

Present
JamesNurthen, MichaelC, Joanmarie_Diggs, MarkMccarthy, harris, CurtBellew, Jemma, carmacleod
Regrets
BryanGaraventa, PeterKrautzberger, StefanSchnabel
Chair
JamesNurthen
Scribe
harris

Contents


<scribe> scribe: harris

New Issue Triage

<jamesn> https://github.com/search?l=&q=is%3Aopen+is%3Aissue+repo%3Aw3c%2Faria+created%3A%3E%3D2020-05-14+repo%3Aw3c%2Faria+repo%3Aw3c%2Faccname+repo%3Aw3c%2Fcore-aam&type=Issues

<Greta> thanks

jamesn: sounds like a 1.3 issue to me

joanie: yea that is fine

jamesn: definitely 1.3 issue

https://github.com/w3c/aria/issues/1270

jamesn: is this (1270) 1.2 or 1.3?

joanie: if its easy cleanup then I'd say 1.2

New PR Triage

<jamesn> https://github.com/search?l=&q=is%3Aopen+is%3Apr+repo%3Aw3c%2Faria+created%3A%3E%3D2020-05-14+repo%3Aw3c%2Faria+repo%3Aw3c%2Faccname+repo%3Aw3c%2Fcore-aam&type=Issues

Decide meaty topic for next week

jamesn: there is the topic of multiselect comboboxes that sina has brought up
... some conversation has already taken place in the slack channel which probably isn't the best place since not everyone is there
... we should let sina voice his views on these
... exposing shortcut keys to AT is another topic
... another topic is: how NVDA is exposing dialogs and some of the issues surrounding that. We probably want NVDA on that but the 9am time is difficult for them so we probably want a different time slot for them

harris: I'm super interested multiselect comboboxes

Jemma: is that topic specific to just NVDA? or could it be more broad to all AT?

carmacleod: if we're talking about checked/selected in comboboxes, perhaps we should discuss those as they related to tables and trees

ARIA 1.2 Issues

<jamesn> https://github.com/w3c/aria/milestone/10

<jamesn> https://github.com/w3c/aria/pull/1261

aaronlev: I forwarded this to alice boxhall for review. This is more her area

jamesn: can we ask her when she might be able to get to it?

aaronlev: sure

https://github.com/w3c/aria/issues/1151

<jamesn> https://github.com/w3c/aria/pull/1224

aaronlev: aria-activedescendant doesnt do anything unless it is on a focused element
... I found that our definition of "owned" is wrong

jongund: I'd prefer to not have that be part of this PR. It is a separate issue

jamesn: do you think this is already covered in another PR? A 1.3 issue

aaronlev: the definition of owned makes it sounds like the ancestry chain can split
... there was another issue that should also be put into 1.3. The definition of required owned elements - you have to say it needs at least one but the example of a non-busy empty listbox
... reading the comments - yea jon I think you've got the gist of it
... the trick of using aria-controls to enable activedescendant. In chrome, we don't enable that as loosely as it says in the spec

jongund: right now chrome limits it to just textbox

aaronlev: yea but we don't go that far up the tree to look for it
... the APG example with the empty listbox could be 1.3
... if the author uses aria-controls and aria-activedescendant NOT on a textbox, then it will break
... we should either change the spec or change chrome
... I'd prefer to change the spec

jongund: we don't want to get ahead of what browser do, do we?
... I don't think we really have a choice

aaronlev: we should meet half way

aaron: change the spec to say its only on textbox

aaronlev: and change chrome implementation

jamesn: so activedescendant in chrome requires the owned relationship?

aaronlev: the part that fires focus events, doesn't care where its coming from
... the part that has the focusable state is different

Live region issues

<jamesn> https://github.com/w3c/aria/projects/13

https://github.com/w3c/aria/issues/712

aaronlev: I dislike aria-relevant
... people speak up about it from time to time. Normally, live region text doesn't get spoken when a node is removed. Say we have a chat log where someone removes a message. Usually the chat client adds a textual indication that it was removed
... the 2nd problem i have is: the difference between additions and text is a bit unclear. Some browsers implement this differently as far as how they handle dom changes
... nobody seems to use aria-relevant properly

jamesn: anybody object to adding this to 1.3

https://github.com/w3c/aria/pull/1072/files

jamesn: should I mark this as low priority?
... possibly superseded by 712
... I've created a bucket dependent on other issues - I've thrown this one there

https://github.com/w3c/aria/issues/322

<jongund> need to leave a little early today

jamesn: it'd be cool to trigger the browser to do what it does for a "real" page load event

greta: I'd prioritize this as high because we use this a lot at washington post
... we refresh the news articles every ~30 seconds

aaronlev: if I'm on an app that is changing browser history. so if I use history back, it'll actually go through the history points

harris: isn't it possible to properly implement an accessible SPA today?

aaronlev: maybe browsers should hook into the browser history api and notify AT?

harris: +1 I like that idea!

jamesn: I put this on high priority. I put it as 1.4

greta: one of the good examples we have is: if we change which article has priority (visually), we don't have a good way to easily say "We've bumped this article up as the priority" or "This article is important right now"

https://github.com/w3c/aria/issues/72

aaronlev: its worth thinking about

https://github.com/w3c/aria/issues/671

aaronlev: theres actual use cases for this

jamesn: is there a spec change needed? or should we close?

aaronlev: seems like core aam thing, no?

joanie: this actually came up in a number of things I've been working on. There are times when the author is repeating the message and other times when it is just even spam
... I don't think this belongs in core-aam

aaronlev: the author has no way of doing this without getting hacky

joanie: orca ignores duplicate events
... this is meaty but let's add it to the deep dive list

https://github.com/w3c/aria/issues/1216

https://github.com/w3c/aria/issues/821

jamesn: can I put (821) that as low?

https://github.com/w3c/aria/issues/832

jamesn: can I deep dive this one?

harris: sounds like a good deep dive candidate

jamesn: I'd love to not have to use the old offscreen live region hack

https://github.com/w3c/aria/issues/1104

aaronlev: i still think log is useful

https://github.com/w3c/aria/issues/1017

+1 to high

rssagent, make minutes

rssagent, stop

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/05/21 18:05:06 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: JamesNurthen, MichaelC, Joanmarie_Diggs, MarkMccarthy, harris, CurtBellew, Jemma, carmacleod
Present: JamesNurthen MichaelC Joanmarie_Diggs MarkMccarthy harris CurtBellew Jemma carmacleod
Regrets: BryanGaraventa PeterKrautzberger StefanSchnabel
Found Scribe: harris
Inferring ScribeNick: harris

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]