November 5, 2019 Authoring Practices Task Force -- 05 Nov 2019

<Matt_King> agenda page: https://github.com/w3c/aria-practices/wiki/November-5%2C-2019-Meeting

<scribe> scribe: MarkMccarthy

Future Agendas

Matt_King: Next meeting on Nov 12, probably on Nov 19 too. The following week is Nov 26, but assuming that's not a good day for a meeting?

carmacleod: right

Matt_King: should we cancel that one?

MarkMccarthy: +1

Matt_King: let's plan on that

Third Working Draft Milestone Review

Matt_King: we have three things left. the first is the next agenda item. the meter pattern is ready to merge

carmacleod: one question on that
... should we remove "or equal to" from the min and max?
... reason being that the min is less than max and vice versa

Matt_King: good point - on those particular ones, yes
... worth checking back through everything. I'll make that fix before I merge it
... good catch, thanks carmacleod
... I wonder if that problem exists anywhere, like slider or spinbutton
... can you look carmacleod?

carmacleod: i'm on it

Matt_King: so the listbox example, as i recall, we are waiting on a couple reviews on the PR
... that's PR 1191
... looks like we just need the accessibility review (assigned to ZoeBijl and carmacleod)

carmacleod: got it

Matt_King: so that's it, all the other reviews are done
... zoe's last comment - visual review is done, would appreciate someone looking at JS. They must have been focused on CSS
... so we wanna land this before we have something ready for MichaelC

ZoeBijl: so what's the deadline then?

carmacleod: i'll review it after the call

jamesn: MichaelC wants to publish a version o fthe APG when he publishes the wide draft so folks have context
... so, ASAP
... but I don't think it has to be published at exactly the same time, but should be close

Matt_King: I saw your note from Joanie that core-aam is ready, so...

jamesn: so MichaelC just has to make sure everything is valid and write the intros. it -could- happen this week

Matt_King: i think we -could- have practices ready this week too
... assuming all goes smoothly, i think we could wrap up everything

jamesn: if something does come up, we could just put in an editors note that we're aware and fixing

Matt_King: also true
... i like that

Naming guidance for blockquote, meter and time roles

<zcorpan> GitHub: https://github.com/w3c/aria-practices/pull/1231

Matt_King: zcorpan, could you share what we have?

zcorpan: yeah. the diff isn't so big for this, fortunately
... there was an editorial change for the text which used to read "not supported by Assitive Technologies" under the time role

Matt_King: did you raise an issue with ARIA about prohibited naming etc.?

zcorpan: haven't done that yet

jamesn: you'll hit resistance on that, though I agree

Matt_King: well, we'll see what happens
... jamesn, are you okay with what we have for blockquote now?

jamesn: sure, your explanation sounds reasonable

zcorpan: "if a visible label is present, associating with aria-labelled by could benefit AT users"

jamesn: sounds good

Matt_King: if people are in agreement, i'll merge. we have an approving review from carmacleod

zcorpan: nice!

Matt_King: no objections, so we'll move forward

Support gap warning and support level note

<zcorpan> GitHub: https://github.com/w3c/aria-practices/pull/1186

Matt_King: we've previously discussed this, and had some broad agreement
... but there was one issue [rummaging for issue]

<jongunderson> https://github.com/w3c/aria-practices/issues/1228

carmacleod: Matt_King, you said we should mention what aria-at is planning to provide and that might be a good note?

Matt_King: so, after reading what's in that issue and discussing what's -not- clear about the 1150 note, i started drafting an alternative to make it more specific
... i think we might need something different. i'll copy it into the minutes

<Matt_King> Matt's proposed wording for issue 1150 note: Because an API for capturing interaction events generated by touch-based assistive-technologies is not yet available, some interactions necessary for this pattern to be fully accessible with touch based assistive technologies are not supported. Authors should fully test this widget with assistive technologies before using it for a production ready...

<Matt_King> ...project.

carmacleod: [reading above text]
... this is only touch, right?

Matt_King: exactly, because there's a few examples that can't be made usable without listening for certain events

jongunderson: like spinbutton?

Matt_King: well, there's ways. but what -will- happen is AT may tell you it's adjustable, but they might not work. could be confusing, but that might be it
... i'm not opposed to adding it for spinbutton though

carmacleod: it is different. I think Mark's was simpler and easier to understand

Matt_King: wondering if we should remove the "authors should test..." text
... it's not fixable, there's nothing to test

carmacleod: true!
... re-reading yours though, Matt, it seems fine

Matt_King: I thought it needed to be more specific because there's a difference in an example not being workable via touch AT because of a bug or because of a bug in the pattern
... but this is saying it's essentially impossible without an API
... didn't want people confused about why that note isn't in more places
... other thoughts?

jongunderson: i think it describes well what the primary issue is, being lack of API support
... so this would only go on those specific examples?

Matt_King: yeah

jongunderson: what about comboboxes?

Matt_King: zcorpan is working on rearraging some things, so that might be addressed then

jamesn: any chance that can be done before 1.2?
... thought that was ready?

Matt_King: well let's close on warning text. i'm gonna add this to the PR and request some reviews. we'll go from there
... carmacleod, can you draft a PR for the support note?

carmacleod: I can do that
... let's agree on words before formalizing a PR

Matt_King: placement and styling as well

carmacleod: yes

Matt_King: so we'll add this to agenda next week

Comboboxes

Matt_King: so specifically about having the APG reflect what the proposal is for the ARIA working draft
... jamesn, in the meantime, if the working draft goes first would you include the wiki page with examples?

jamesn: that link is in the editors note

Matt_King: okay so a stopgap. good. so if MichaelC publishes on friday, i don't think we can have all the combobox stuff ready by then
... zcorpan is avaiable to start working on that on monday. Simon, if you start focusing on the pattern, and we have the example from Jon ready...
... we couldn't rework every example prior to this, but maybe we could get two examples sorted.
... and merge into 1.2 branch
... so we'd have 3 examples and a pattern
... i kinda wonder if Jon might be able to take a stab and branch off the grid popup combobox
... (or anyone else)

jongunderson: i could take a look

Matt_King: what we'll do though is make one combobox example directory
... the pattern will only be one way of doing things but have a note

carmacleod: cool

Matt_King: so it'll simplify everything

jamesn: so carmacleod noted to me that the comboboxes don't work with safari + VO

MarkMccarthy: yeah, there's a safari bug I think

jamesn: works fine in Chrome

[chatter about bug]

Matt_King: well let's not debug it here, we can talk more about it next week

<zcorpan> (is there a webkit bug filed?)

I'm looking

I remember flagging it for a project a few weeks back

Matt_King: not sure if MichaelC might be keen on this, but we could publish twice? to the same URL? so everything is ready and out there, but we can merge one more thing in once it's ready
... we could put in an editors note as well that another change is coming
... might that fly jamesn?

jamesn: possibly

This may be the issue at hand, regarding the comboboxes: https://bugs.webkit.org/show_bug.cgi?id=202198

in Safari 13, select boxes with optimize legibility crash the browser

jamesn: we should publish with a note, that's fine

Matt_King: okay, we can discuss with MichaelC
... so Jon, can you look at the grid one?

jongunderson: I'll check it out, yeah

Guidance on widget state attributes

Guidance on aria-level

<zcorpan> GitHub: https://github.com/w3c/aria-practices/pull/1109

<zcorpan> Link to preview https://pr-preview.s3.amazonaws.com/w3c/aria-practices/pull/1109.html#aria-level

Matt_King: i see carmacleod, you reviewed this. i have a couple of questions related to this that'd I'd like to ask the group
... on section 8
... some people might be annoyed by this, but we have describing hiearachacal struction inside section 8, but i feel it might be nicer for those scanning by heading if we mentioned aria-level
... in other words, a little redundancy may be helpful for those scanning by heading, to make sure you're in the right place
... can be some work to scan back up

jongunderson: I think that's a good idea. search engines will pick up better too

carmacleod: true

+1 Jon

Matt_King: kudos to Simon, I love the use case of using the heading role vs. element, putting it in SVG. awesome

zcorpan: thank you!

jongunderson: i'm not sure about the listitem example

Matt_King: the idea being you're quoting a portion of a list that's nested deeply. is it not clear? or do you disagree with the use case?

jongunderson: I just don't really get it. why would I care what the original order is?

zcorpan: so, if the original list has several nested lists, then you'd get a little more context of the original

Matt_King: you'd have to read the last paragraph really close. do you have a better example? It might not be super realistic

jongunderson: what's the blockquote for?

Matt_King: idea being you're showing a snippet of the list not the entire list

jongunderson: if you're using aria-level on a listitem and that item isn't in a container, what's gonna happen?
... other examples like this - if you have a long list of stuff and the DOM only has some of it. wouldn't it have ULs instead of blockquotes?
... using -posinset and -setsize in addition to -level?

Matt_King: but are those supported on list elements (ULs for example)?

jongunderson: yeah

Matt_King: that might make this clearer
... it'd be nice to have an example that makes it more apparent why this is needed. just hard to come up with a good one
... they don't come up IRL very often

zcorpan: a table of contents list that's broken into chapters in books?

Matt_King: like 1.1 in the listitem or something?

zcorpan: right, but only viewing a subset of table of contents for the book. not including the top level chapters, but semantically you'd still see them as second level items

Matt_King: that might be clearer

zcorpan: i can try to change that

Matt_King: I have a question on the one with treeitem
... it'd be nice to have a clear example we're using a tree for something interactive
... suggestions?
... or similar concerns?

[silence]

Matt_King: well, Simon, combobox will be a higher priority than this for now. we'll circle back!
... thanks everyone for today

- DRAFT -

November 5, 2019 Authoring Practices Task Force

05 Nov 2019

Attendees

Contents