ARIA WG

<joanie> agenda: this

<joanie> agenda: be done

<MarkMccarthy> scribe: MarkMccarthy

New Issue Triage (https://bit.ly/329F3se)

<joanie> https://github.com/w3c/accname/issues/77

joanie: [reading through issue text]
... oh, there's a proposed solution, seems mainly editorial. how about accname 1.2?

bryan: sounds good

sina: can you clarify a little why it's behind core-aam etc.?

joanie: just the release schedule

sina: but accname doesn't participate in a similar coupling?

joanie: up til now, no, because we have a little more flexibility for changes
... for the most part, name calc is independent of the rest of aria

sina: thank you!

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

joanie: lots of great discussion on braille stuff - this is different

carmacleod: sorry, just didn't understand

pkra: i agree, we need to work on this, jus wanted to get those other things merged first. assign to me, i'll take care of it

joanie: cool, looks easy!

sina: if you need a reviewer, i'm happy to

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

joanie: encapsulation is landed in 1.2, right?

carmacleod: yes

<pkra> I didn't expect to avoid Sina's review ;-)

joanie: is it stable?

mck: we pulled it out i think
... we didn't do it in the APG naming and describing yet, because it wasn't gonna land in 1.2

carmacleod: ah so its in the newest...

joanie: marking for 1.3 because it's not in stable WD yet

carmacleod: 1.3 works, 1.2 doesn't make sense

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

carmacleod: this isn't urgent, can definitely be 1.3

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

<joanie> According to the HTML spec, <header>s inside <section>s, <article>s, etc. don't take a landmark role (outside they would have role="banner"). Currently it appears this is hardcoded to those exact HTML elements. Should that be extended to be based off the ancestor's ARIA role instead, so the same behavior happens to <header>s inside e.g. <div role="region">s?

joanie: thinking this is a 1.3 thing, seems like it'll involve lots of discussion

mck: sounds similar to James Craig's discussion, too

pkra: that was more about heuristics though, right? this is more explicit

joanie: this seems more scoped to sections
... 1.3 on the basis that 1.2 was editorial

[no objections]

carmacleod: this seems editorial too, maybe

joanie: might not be though

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

joanie: this smells editorial

sina: i'm the reason for this. 1) is this the right place for this question? 2) i'd love some clarity on this

joanie: this is a case where something changes on focus?

sina: while your focus is on something, if aria-describedby is changed, what should happen? basically we're just asking the spec for clarity

mck: spec is silent on this, Apple has said they're not interested in -describedby working in any automatic/dynamic way
... so it's always ctrl-opt-shift-h, and they don't tell you it's there most of the time

sina: if it's going to work less well with Apple, then so be it. but for Windows?

Bryan: i thought there was an accessibility API, description change event, is it still in there?

joanie: one issue is can we map it, another is what should screen readers do - if this is a good approach anyway

mck: consensus now is, -describedby isn't a live thing. so if it changes, user won't know. make it live if you want it live

bryan: some years back w/ tooltips this came up. should there be something like recognition when -describedby changes, like if focus changes and a new DOM item comes into existence.

multiple: this isn't addressed by spec

joanie: and not 1.2 at least

mck: right

sina: could this go in 1.3 or should I have james file it elsewhere?

joanie: filed it for 1.3, not necessarily committing to anything. might need to be addressed in multiple places

sina: great - it's just that chrome and firefox do different things. good to know

bryan: i checked the a11y tree when this happens, the description property changes. in theory, it comes down to AT if they recognize that.

sina: in what browser?

bryan: firefox and chrome. happened last time I checked

aaronlev: the tree updates with changes, but we don't fire an event. maybe we should consider the use case and do so
... i've been asked by the Docs team to do something like this

mck: i agree - i think this ties in to the bigger discussion of aria-live in 1.3
... and what the browser behavior should be
... right now aaronlev, you're following spec and spec doesn't say anything about firing an event

aaronlev: and how would AT know then?

carmacleod: esp. name changes

mck: well AT is continuously monitoring, screening out extra events
... anyway, this is a useful discussion

sina: great, i'd love to be part of it

<joanie> https://github.com/w3c/accname/issues/76

joanie: already triaged this, this was from a colleague.
... tl;dr where does the accname come from for these pseudoitems?
... 1.2 because we want consistent markers

<aaronlev> just a note that MSAA does have an event for description changes: EVENT_OBJECT_DESCRIPTIONCHANGE

<aaronlev> so for windows we don't need to invent anything, just follow the existing api requirements

joanie: maybe a solution will be to talk about pseudo stuff anyway

sina: this has potential to destroy list reading experiences though

bryan: so how would this work? putting aria-describedby in something that has a list? would that read out all the bullets etc. too?

sina: that's what I'm assuming, esp considering the list item type (filled in black square, bullet for example)

mck: right, like when AT reads the name of the character

sina: so we need to come up with something that's not just prepend

joanie: the example that my colleague showed me was replacing roman numeral markers to something like foo.0
... but the accname was incorrect
... and the i. that wasn't rendered was exposed

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

joanie: is this for the aria spec or APG?

mck: authoring?

carmacleod: no, it's asking for a change to spec
... or thinking about it, possibly allowing non tab children in a tablist

mck: we come across this a lot, there's good reasons for it

joanie: 1.3?

mck: yes

<joanie> https://github.com/w3c/accname/issues/75

joanie: this one will be 1.2 because it's for accname
... jamesn took care of this, not sure why it showed up

pkra: related to last topic, potential of -describedby changing, right?

joanie: no, this isn't exactly that

bryan: is this the one I commented on?

carmacleod: yep

bryan: you'd have to repeat the same algorithm twice with this, which would throw off recursivity

pkra: so, assumption is the implicit wrapper is name not description, even when referenced with aria-describedby?

bryan: yeah

mck: in both cases, you want to calc what the content is in the exact same way
... so, pointing at a node that has descriptive content vs. the name - in both cases we're trying to pull out text of that node. uses the same algoritm
... when you're calculating the text content you wanna do it the same way

sina: fair

MarkMccarthy: carmacleod is taking over scribing

New PR Triage (https://bit.ly/2SVUJeo)

<carmacleod> scribe: carmacleod

<joanie> https://github.com/w3c/aria/pull/1198

joanie: james has writtten this PR as a draft

<joanie> https://github.com/w3c/aria/pull/1197

joanie: Matt, can you talk about this?

mck: the 1.1 version of combobox used to require a textbox, which inherits aria-multiline
... but in 1.2, combobox doesn't support aria-multiline, so that sentence doesn't make sense
... so I took it out

joanie: normative change?

carmacleod: typo?

mck: normative mistake

joanie: squash and merge!

Wide Review Comments with PRs (https://bit.ly/2P9gPZV)

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

aria-haspopup is no longer global

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

<joanie> https://github.com/w3c/aria/pull/852

carmacleod: related PR https://github.com/w3c/aria/pull/852
... waiting on Matt and James to review
... Question, can I delete "host language" in this phrase: User agents MUST NOT expose host language elements

mck: Yes

Wide Review Comments without PRs

github: https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3A%22WR+comments%22+-label%3A%22has+PR%22+

joanie: They are all assigned to someone - does anyone have questions for the group?
... these specifically have the tag "wide review comments"
... this means that each one has to be addressed one way or another

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

joanie: this one "needs info" - will tag it

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

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

joanie: Better aria-expanded defaults for combobox
... Matt has raised some concernes... Sina, do you have any comments on this?

sina: it's on my tomorrow list

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

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

joanie: Missing definition: current element

mck: I guess I agreed to look at this...
... this is 1.3

joanie: I've unassigned you and will assign to Wilco

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

carmacleod: I will add "Generic containers are exposed to the API so that assistive technologies can gather certain properties such as layout and bounds."

joanie: please add "has pr" label

carmacleod: yep, will do

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/on demand/landed/
Succeeded: s/palces/places/
Found embedded ScribeOptions:  -final

*** RESTARTING DUE TO EMBEDDED OPTIONS ***

Present: tzviya Joanmarie_Diggs MarkMccarthy carmacleod jamesn harris Scott_O pkra janina aaronlev Bryan_Garaventa Jemma Matt_King Irfan StefanSchnabel
Regrets: Curt James Jon Michael Scott
Found Scribe: MarkMccarthy
Inferring ScribeNick: MarkMccarthy
Found Scribe: carmacleod
Inferring ScribeNick: carmacleod
Scribes: MarkMccarthy, carmacleod
ScribeNicks: MarkMccarthy, carmacleod

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.)