January 21, 2020 Authoring Practices Teleconference -- 21 Jan 2020

<Jemma> https://github.com/w3c/aria-practices/wiki/January-21%2C-2020-Meeting

<scribe> scribe: MarkMccarthy

Release plans

Matt_King: A big focus next week is carousel pattern, we've gotten lots of good feedback on it

<Jemma> https://github.com/w3c/aria-practices/wiki/Release-Plans

Matt_King: right now we're kind of working in parallel - under releases in progress, it's easy to see what we're working on

jamesn: yeah, sounds like a good approximation
... thinking as soon as we publish the CR for 1.2 we'll be ready for a WD of 1.3
... but we might need to branch APG before that

Matt_King: right, okay
... primary message, though, is we have two things going in parallel
... we'll be kicking off work on APG 1.3 soon

jamesn: bigger question - are we gonna do something like master and stable branching system?

Matt_King: thinking stable will be the version branches
... what we put in master -- i generally try to make sure it's everything that's merged
... I don't like cherry picking

jamesn: me either. but could be a problem if things don't make 1.x and they have to be pulled out of that 1.x branch

Matt_King: yeah, and we have done that, but if there's something we missed we should watch out

jamesn: that's what master/stable can help avoid. nothing pushed to stable until propogated
... but the master would satisify ARIA reqs

Matt_King: hoping to get rid of versioning entirely, but that's kind of far away
... for this year, though, i'd rather keep things pretty much the same

jamesn: as long as you're alright with the extra work that might entail, that's fine

Matt_King: yeah, and it might be good to have guidance for future work

jamesn: +1

Matt_King: another release of 1.2 sometime in the summer too, with more info. targeting 1.3 at the end of the year
... we'll dive deeper into 1.2 release priorities next week
... still 59 issues in that milestone

Dropping IE Support

Matt_King: i think Sarah got us convinced when she said Microsoft isn't even supporting IE anymore
... that being the case, I think it's good timing for 1.2 rel 1 to officially drop support
... any objections to formally dropping IE support?

[silence]

ZoeBijl: no objection

carmacleod: no objection

<jamesn> enthusiastic endorsement from me

Matt_King: That's great! So, I know one place we need to make a change is the read me first section. is there anything else we should do?
... should we have an active effort to find all issues based on IE and formally close them? that might be good

ZoeBijl: maybe we have some IE11 specific code in CSS, that might need to be cleaned up. or landmarks part

jamesn: we might take out recommendation to double up roles

ZoeBijl: that's why i was asking jongund about landmarks

<Jemma> First thing we will do is update "Read Me First" section regarding IE support.

jongund: I don't think we did that in the examples, but we can look

Matt_King: anyone that can create an issue and help go through references or things that need changing?

jamesn: would we go so far as to change examples which might be better if we didn't support IE? I hope not

Matt_King: i don't think we'd redo whatever already works. but if we're actively working on it, then yeah

jamesn: okay, right

ZoeBijl: nothing in the CSS to change specifically, so that's clean

Matt_King: we had one issue related to build process, changes we didn't make. they were hypothetical at the time...

ZoeBijl: there's also a JAWS-test issue on color contrast that has a lot of IE11 stuff we can ignore

Matt_King: any other outward signaling we should do? we could call this out in an announcement

Jemma: I'm happy to help where I can, but have a few things to ask in our editor meeting about it.

Matt_King: okay, no problem
... So be it, we have consensus on this.
... can someone create an issue to make this change?

carmacleod: i'm on it
... I just asked Sarah if she had any objection, she said Nope!

Tabbed Carousel

Matt_King: this is PR 1120 where jongund has done lots of work
... there was lots of review activity too
... i also have a question about how we're doing multiple versions. but first
... i started the editorial review. functionally, carmacleod is done and she approves, thank you.

carmacleod: you're welcome.

Matt_King: vis design, Zoe you're signed up for that and a11y. not seeing an approving review yet
... any updates?

ZoeBijl: I've only gotten back to W3C work this week, so if I didn't check it, it's not done.

Matt_King: overall the group is pretty happy but still want to check in with you

ZoeBijl: either way, I haven't gotten to these checks yet and will do so before next Monday. If anyone else can assist, by all means please!

Matt_King: Sarah isn't on the call but approved, so are we good here?

jongund: not sure what the complaint was about

Matt_King: so let's request a re-review, just to make sure we're up to date

carmacleod: Matt_King, you also wanted to minimize the code. so jongund, maybe it was easier to put it in two files that way?

jongund: i can put them back into one. it seemed simpler in two files to read what was going on, but I can put it back into one.

carmacleod: tl;dr - there was a problem where the mouse was supposed to stop the carousel from spinning. it wasn't spinning when I put the cursor just above the carousel, and it turned out to be a sizing issue. jongund fixed it (yay!) but it was split into two files because of that

Matt_King: and that was the version where the controls were on top of the images?

carmacleod: yes

Matt_King: so jongund, you were worried about the complexity of the code then? i didn't do a comparison, but...

jongund: the only change is basically what CSS is linked and the aria-current
... i split them into two files because I Thought I had to do something with the DOM, but I didn't. They were split to make the work easier on my end, but I can recombine them.

Matt_King: with the script in the HTML itself?

jongund: yes

Matt_King: cool, I don't want to have to make editorial files in two places if necessary, also we don't want to have to maintain a few versions. I'll do editorial review after that

jongund: I'll do that now

Matt_King: Thanks!
... we're really close on this one, awesome.

Support gap warning and support

<Jemma> "Users of touch-based assistive technologies may not be able to fully operate widgets that implement this pattern because APIs for capturing the necessary gestures and commands from assistive technologies are not yet available. Authors should fully test widgets using this pattern with assistive technoligies before considering incorporation into production systems."

Matt_King: I pulled the text I pushed before the meeting, it's in the agenda as well as a link to see in context. Can someone read?

<Jemma> https://pr-preview.s3.amazonaws.com/w3c/aria-practices/pull/1186.html#slider

carmacleod: sure. [reading warning note - pasted above]
... I noted a small spelling error, already commented on it in the issue

<Jemma> typo for "technoligies"

carmacleod: otherwise, "Gestures and commands -from- AT", so...
... when you do a swipe and AT is running, then the AT passes it through to the widget?

Matt_King: right. the gesture event is a swipe up or down, that is issued by the AT to the widget

carmacleod: so "from" is the right word, then.

Matt_King: yes, correct.
... it was previously worded that made it seem like it was the AT's fault something wasn't working, which isn't true.
... I also tried to convert it into a more active voice, rather than a passive one. focusing on users and their experience.
... the meaning change was to make it clear that the APIs needed don't yet exist. not pointing a finger at AOM, browsers, etc. but just an observation of a multi-tiered problem
... I also changed the authoring guidance a little bit; before it was about testing, but I don't think people would want to considering incorporating these into production systems. so the real takeaway is "do you want to use this at all?"
... so I tried to capture that
... doesn't affect desktop sites --

jamesn: it does
... think of Windows desktop machines with touchscreens

Matt_King: yes but they also have keyboards that can perform the same gesture

jamesn: sure, you -can- use JAWS on a touchscreen device without a keyboard, right?

Matt_King: you -can-...
... but, I suppose I'm not sure how all that would be interpreted. i.e. not sure what events JAWS proprogates for certain gestures on a touchscreen.
... so that might be worth investigating in the future

jamesn: true. so yes, you could theoretically do a lot of this, but not advisable

Matt_King: another question here - what patterns does this go on?
... so the biggest question, but it on tree...?

carmacleod: the statement on tree came from a 2015 comment
... [reading comment about menu and tree interaction w/ voiceover]

Matt_King: they should open with click though, right?

carmacleod: they -should-

<Jemma> https://github.com/w3c/aria-practices/issues/8

carmacleod: [reading comment on tree behavior with voiceover]
... keep in mind, these comments were from 2015

Matt_King: this is something we should investigate, essentially if the double-tap to activate in voiceover and talkback is sufficient and captured by the right element
... or, is the problem that we only support clicking on the + and - and not the actual name itself?

carmacleod: good question

Matt_King: but, the way I understand it, it doesn't seem like an API issue

carmacleod: i'll look into these issues; we don't have an example with submenus do we?

Matt_King: in the navigation menu example, which needs some mouse work

carmacleod: tell me about it!

Matt_King: i'll copy this warning into the multi-thumb slider. after that, is this ready to merge?

carmacleod: yeah! can always be copied elsewhere

MarkMccarthy: +1

carmacleod: our file viewer, double click opens and closes. that seems odd

Matt_King: well we don't document mouse behavior. sounds like something to address

ARIA 1.2 combobox

Matt_King: so, we have two primary things to accomplish for rel 1 of APG 1.2

<Jemma> https://github.com/w3c/aria-practices/projects/7#card-28909395

Matt_King: we have four combobox examples but need some bug smashing
... we also have a PR from jongund in the works on a date picker
... but what I want to work on today is triaging the bugs

<Jemma> https://github.com/w3c/aria-practices/projects/7#column-1413589

Matt_King: there's 21 issues under the next steps column. what i'd like is to reduce the next steps and in progress to represent what we're doing for rel 1 (March)
... under do later, we only have three

<jongund> https://github.com/w3c/aria-practices/pull/1276

Matt_King: so what could be moved off to do alter, or if people want to be ambitious and get a lot done before March...

jongund: what about PR 1276?

Matt_King: right, that's supposed to close many of these. does that link to what's being closed, Jon?

jongund: 1268, 1265, 1263, and escape behavior. also updates regression tests
... so maybe let's review this PR and see what remains?

Matt_King: that seems reasonable.
... first thing it addresses is 1066, escape key. so that's good.
... what about issue 982, an issue on.blur... what's this for?
... basically, making it work for people using the keyboard and mouse at the same time

jongund: I can look at it.

Matt_King: so then, we've addressed everything in 1263, 1265...
... what about "authoring practices should address blur behavior", issue 569
... jamesn, opinions?

jamesn: that's old!

Matt_King: yeah...
... i seem to remember you, jamesn, having comments about something similar...maybe we just discussed it or something

jamesn: i have no problem documenting that if we need to. is that normal behavior?
... for a native select, doesn't it depend on how you open it what the normal behavior is?

Matt_King: depends on the implementation

jamesn: maybe we should put in the documentation that people should make a conscious decision about its behavior, before implementing it

Matt_King: what we -don't- do in most example is consitently specify tab behavior, which is what we're talking about here

jamesn: or any blur behavior. so when you tab or click out, what happens

Matt_King: yeah. so, really, this seems like a documentation thing, not a bug. i can take this after all, this should be an easy one
... issue 1267, touch based screen readers. have we tested that? what's the status of our current examples with voiceover on ios or talkback?
... can someone look at that and comment on issue 1267?
... or, opinions on how important this is for March release. this is probably one where we ought to make the examples work on mobile

carmacleod: Yeah, I think so.
... I can test this. I think Jon's issue that closes the easy things should be focused on first. then we tackle some of the rest of this

Matt_King: okay, so top priority is merging 1276.
... then we can better address 1267

carmacleod: I think so, yeah

Matt_King: so jongund, if there's any other testing or reviewing needed for 1276 we'll try and get it done this week

carmacleod: there's people listed for review, maybe we nudge them?

Matt_King: yeah, that'd help clean this up

aria-live guidance

Matt_King: i'm behind on this. i saw a -ton- of email convo going on. is there anyone who can catch us up that's on the call?

carmacleod: that might've been some of my editorial stuff... but in general, aria-live support is not robust cross-platform, in even some pairings. for instance, i had an example working great on Win, but awful on Mac. and vice versa
... JAWS-test has written a bunch of recommendations in 1278 and, not saying they're all good, but they merit discussion

Jemma: we talked abou this at the ARIA meeting too, right?
... I thought we did...

<carmacleod> https://github.com/w3c/aria-practices/issues/78#issuecomment-529846994

Matt_King: so, we're at a place where we know the WG needs to improve this. but can we provide guidance? such as, what are the most common use cases, or what works best in real life.
... the ARIA-AT project and WG can work on making things better, but if we can provide guidance even on some robust examples, that'd be good

carmacleod: we probably need to do lots of testing though. one thing that I did working best in most places was duplicating aria-live and role=status

<Jemma> https://github.com/w3c/aria/issues/1139

carmacleod: but I don't remember the details, so I'd have to do it again

<Jemma> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+aria-live

Matt_King: Sarah and Bryan have stuff working in the real world, other people do too, so maybe we tap in to that
... if we can piggyback on some working, practical examples, at least we can convey some working things

carmacleod: i'd encourage people to read the JAWS-test list. like make sure that authors know live output is flat text, only once, etc.
... a bunch of thoughts that have been tripped over

Matt_King: that's good input.
... thanks very much everyone - talk to you all next week!

- DRAFT -

January 21, 2020 Authoring Practices Teleconference

21 Jan 2020

Attendees

Contents

Release plans

Dropping IE Support

Tabbed Carousel

Support gap warning and support

ARIA 1.2 combobox

aria-live guidance

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output