<Jemma> rsagent, make log world

<scribe> scribe: MarkMccarthy

<Jemma> Meeting Agenda : https://github.com/w3c/aria-practices/wiki/January-14,-2020-Meeting

2019 look back and 2020 look ahead (10min)

mck: we're moving the support gap note agendum to another meeting

BGaraventa: what's the F2F dates?

jamesn: May 5-7

ARIA Face to Face

Matt_King: we haven't decided on the location for sure, right?

jamesn: we put it out there for Dublin, and that's on!

Matt_King: oh okay, awesome.
... I can only host 10 people, so I'll have to get another FB employee to help

jamesn: so we've already got 7 people registered, so we'll be over 10

Matt_King: Okay, so May 5, 6, 7 at Facebook's Dublin office. Anyone else plannign on making it?

jongund: I'm thinking about it

jamesn: My gut feeling is we'd like one day of the three dedicated to authoring
... we're hoping some other EU participants can make it over

Matt_King: and we're thinking that the authoring things are things that the whole WG would care about too
... I'd also like to share at that time how we're doing with ARIA-AT

<Jemma> https://www.w3.org/WAI/ARIA/wiki/Meetings/F2F_Spring_2020

Matt_King: we're well on track at the moment, and I've got some contracts in place, so hopefully movement will be starting to get quick soon, and we'll have lots of news by May 7
... so there's lots of interest James! Jemma, are you thinking about it?

Jemma: I'm inclined to attend, yeah

2019 look back and 2020 look ahead

Matt_King: looking back, compared to the start of last year the TF as a whole is a lot healthier and active
... we've made a ton of progress as far as what the APG covers, provided lots of guidanace, made a big step to getting to a higher quality product
... got some intense feedback about our code quality and now we're continuing to improve that
... I have a lot of gratitude towards everyone for making this happen; so awesome to see you all putting your heart into this.

s/o fguidance/of guidance

Matt_King: anyone else have any other opinions?
... looking forward, we'll have ARIA 1.2 becoming a spec, so APG 1.2 will be our first big deliverable
... from a prioirty standpoint, we're agreed that quality is something we're striving for and focused on. Zoe talked about an end to end audit to work on improvement; I want to support them in that
... Not all of ARIA is covered yet, we need to work on closing that gap.
... I hope to see the ARIA-AT project feeding some info into APG to help people know what works/doesn't as far as the patterns are concernred
... might start with desktop only, mobile maybe 2021. But any amount we can get in (sustainably) now is immensely helpful
... last year the big addition was automated regression testing, so hopefully -AT will be the same this year. along with 1.3
... what else do folx think is important to prioritze?

jongund: Looking at more basics, like input enhancement; I also see lots of issues with navigation menus that could be helped with more guidance
... those would also be important for AT testing

Matt_King: Good points. a goal for the -AT testing is to figure out where we can improve patterns or ARIA to make things clearer
... at the content level, I agree that menus are still problematic in some ways

sarahhigley: that reminds, taking a look at common misunderstandings of the APG and how we can mitigate that.
... like day-to-day use from devs, for example

Matt_King: are you suggesting collecting misunderstandings in one place?

sarahhigley: yeah, we get a trickle of issues and I also see lots of this in my workplace. so having somewhere to collect that feedback and looking broadly on how to improve might be good
... structure/architecture wise. we can't foolproof anything, but could probably improve

MarkMccarthy: +1 to that sarahhigley!

Matt_King: we're not going to put anti-patterns into the practices, but if we know there's confusion that does point to issues in the patterns

<dbass2> how about code example library?

sarahhigley: there might be little bits of both, hence my interest in gathering feedback in one place. or like what jongund's mentioned about linking back to parent items/readme's etc.
... or linking back to the rules, or basic parts of patterns. that these things are here for a reason. surfacing guidance where it needs to be surfaced.

Matt_King: right, and that kind of gets to the usability of the guide itself, which might be kind of inhibited by it being a note
... one of the things I'd like to entertain is converting APG into a website, kind of like WAI Tutorials. so its scope *can* do what you're describing sarahhigley
... but expanding scope is a charter thing, an increase in effort thing, etc.
... not to say we can't improve before that

sarahhigley: agree with all of that

<jongund> got to go

sarahhigley: there's probably some things that are easy to do or not as destructive.

Matt_King: for instance how we link info about aria-activedescendent - i'd like to see more of that
... so lots of input on the content. lots of stuff to do!
... the mailing list is also a good place to raise issues or just discuss with anyone about anything! or ask me/Jemma to add items to the agenda

aria-live guidance

Matt_King: we have a PR for this, carmacleod put a bunch of comments in here

carmacleod: yeah... [chuckle]

<Jemma> https://github.com/w3c/aria-practices/pull/1027

Matt_King: since you added info, did you want to discuss?

carmacleod: it was mostly editorial. the one thing that isn't is role=region

Github: https://github.com/w3c/aria-practices/pull/1027

<Jemma> https://github.com/w3c/aria-practices/pull/1027#discussion_r366310011

carmacleod: do we want to take the role off completely, with a blank div?
... i believe that, probably, it was written that way because it made sense and the examples didn't want to use something that wasn't ready yet, so region was used (vs status or something similar)
... so, do live regions need a role? should they have a status role? be on a div? etc.?

Matt_King: they can be just on a div, paragraph, li, anything. so we don't want to necessarily use role=region; not to mention confusion of live-region and role=region

<sarahhigley> :D

<sarahhigley> <div aria-shouty-bits="extra-shouty">

Matt_King: live content is same as any content, so we can fix the examples, but you raise a question that might not be adequately addressed in the guidance
... such as what should the live region be on

<Jemma> https://www.w3.org/TR/wai-aria-practices-1.2/#aria_lh_region

Matt_King: we listed the properties in the beginning, with a table in the beginning summarizing differences between everything. maybe there's an oversight, or and editorial bias...
... maybe we should get rid of some of these things that don't need to be there very often (like marquee, log)
... perhaps some bias on my part that we didn't summarize those. did you find the structure confusing?

carmacleod: no, it made sense. but, you don't want to use the roles before describing them. it's a spec thing.

Matt_King: we DO want to describe the properties, though.

carmacleod: so, maybe we delete role=region
... but, one of those had a label. a contacts list where Alice came online. maybe that should be a landmark. so a landmark region?
... but, that depends on the app etc. but a contacts list is a landmark IMO

<jamesn> agree with the contacts list one remaining a landmark

Matt_King: a few people including Scott and Bryan, JAWS-test maybe; we've thought about what the reliable changes are that trigger a live region to activate

carmacleod: 5.1.4 (triggering live regions) discusses some of that, and I called that out too as needing more
... there's lots of info that implies what triggers stuff, but needs lots more concrete description

Matt_King: is there someone that can help out with this?

<jamesn> https://w3c.github.io/core-aam/#mapping_events_visibility is where this should be defined isn't it?

Bryan: I've actually wanted to research this, and probably could. technically, it also works when a DOM node is added; when CSS is added. this all depends on whether AT picks it up and announces it, that's the unreliable bit

Matt_King: I should go back and discuss with an eng. I was working with here; we found a way that seemed pretty reliable, but I don't remember what we did. I remember it being super easy
... in anyone's experience - is there a really short list of ways that ALWAYS work?

sarahhigley: NO
... [chuckle]

Bryan: most reliable is adding HTML to an element with aria-live="polite"

sarahhigley: doesn't always work though

Matt_King: what we did was take content out, put it back in to the element, and then it'd work. kind of depended on how different the content was

sarahhigley: other considerations though like memory, DOM weight, focus,
... there's weird stuff that happens
... probability of it not working scales w/ complexity of code. and sometimes also, it just doesn't work because the moon isn't full [chuckle]

Bryan: recently, we've been trying to make error handling more reliable, devs want to automatically render an error tooltip that, upon rendering, is announced. So the live region is being added to the page, and that's what they want announced.
... it works sometimes, but is not reliable

Matt_King: seems like if there are some *mostly* reliable techniques, we should add them here

sarahhigley: yeah, there are some I can think of. but they have a few caveats, like where the live region is located in proximity to another element; if a region should be pulled in; pulling content out of the region; etc.

Bryan: similarly, I think it's really weird. and, it's good to say you can't fully rely on live regions to make something hugely accessible
... people also put role=alert on something, expecting it to be announced when a page is rendered, and it isn't.

sarahhigley: except sometimes it is!

Matt_King: but it's not distinguished?

sarahhigley: some screenreaders do that, NVDA i think?

MarkMccarthy: yes

Jemma: a suggestion - why don't we put *all* this info into one place and we can start there? a comment or new issue about status of this topic and we can figure out next steps

Bryan: I don't think it's wise to make a compatibility table, but listing ways content can be added and how that affects live regions and vice versa. that should be fairly easy to distinguish and won't change *as much*.
... also, our goal is to standardize support, and this should help.

CurtBellew: does it help to associate those methods with a use case?

Bryan: yes and to identify different methods to recommend a live region, what constitutes a supported live region

Matt_King: we could change that section on triggering live regions to something like "triggering AND common use cases" and listing some use cases along with reliable methods

<carmacleod> Live region guidance issue: https://github.com/w3c/aria-practices/issues/78

Matt_King: maybe that's a good idea. I'm happy to help clean up editorially, if folks could add comments to the issue.

carmacleod: there's already a bunch of comments from JAWS-test about what works/doesn't. they've listed many things they've noticed so far

<Jemma> https://github.com/FreedomScientific/VFO-standards-support/issues?q=live+region

Matt_King: even if we had like 4 common scenarios; form field error, something on single page apps, on page load; those could be good. sarahhigley, Bryan, MarkMccarthy could you add some comments to that?

<Jemma> loved solution!

CurtBellew: something else to consider is an incoming chat message

sarahhigley: or also app-wide push notifications

Tabbed Carousel

Matt_King: just waiting on my review...

carmacleod: i haven't checked off my functional tests yet, but almost done. My Mac needs a kick

<Jemma> https://github.com/w3c/aria-practices/pull/1120

Matt_King: glad it's not one of us

[group laughter]

carmacleod: in general pretty good, functionally alright!
... **so far**

Matt_King: Zoe was down for a couple of these; Jemma did you write to them?

Jemma: yes, and I think carmacleod and sarahhigley got a message too

carmacleod: I should've

sarahhigley: yeah

<sarahhigley> it was a good reminder after the holidays, thanks Jemma :)

Matt_King: so, 1.2 is still going to be a little while; proposed recommendation around CSUN, so I think we could wrap this and get it in by the end of the month
... at least, I'd like to.

carmacleod: should be pretty close. should look at sarahhigley's suggestions

sarahhigley: but my comment doesn't need to bar a PR

<Jemma> https://github.com/w3c/aria-practices/pull/1120/files/b6aeffb39b8fc6caa3033ec63bc58c8c97f1bef5

carmacleod: it's about leaks though?

sarahhigley: yeah... it's not a pattern i really like, but it's elsewhere too. so what's one more? we can clean it up later

Matt_King: got it, so won't hold up merge, but one less thing to do if we sort it now. let's see if jongund has time
... running out of time for combobox, so we'll move that to early agenda next week.
... let's wrap up on time today, unless any last comments?

Jemma: thinking of taking visual review for carousel if Zoe is busy.

Matt_King: I'm good with that, if they're struggling on getting it sorted.

Jemma: but what about "typical modal presentation"?

carmacleod: seems good to me!

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/present_//
Succeeded: s/intens/intense/
Succeeded: s/o fguidance/of guidanace/
FAILED: s/o fguidance/of guidance/
Present: jamesn sarahhigley Jemma jongund carmacleod MarkMccarthy CurtBellew BryanGaraventa
Found Scribe: MarkMccarthy
Inferring ScribeNick: MarkMccarthy

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