<joanie> agenda: this
<joanie> agenda: be done
<MarkMccarthy> scribe: MarkMccarthy
<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
<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!
<joanie> https://github.com/w3c/aria/issues/1183
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
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.)[End of scribe.perl diagnostic output]