<mck> rrsagent make log public

<jemma> trackbot, start meeting

<trackbot> Meeting: Accessible Rich Internet Applications Working Group Teleconference

<jemma> https://github.com/w3c/aria-practices/wiki/August-13,-2019-Meeting

<scribe> scribe: MarkMccarthy

Future meeting agendas

mck: the next meeting is next week 20 Aug. as usual, if you have a topic let Matt or Jemma know
... hoping to have milestones sorted by then

<jemma> regret+ sarah_higley

mck: PRs are getting lower attention for now while we get milestones sorted out and TPAC things sorted out

jongund: okay, just want to get some pulls merged before stale

APG 1.1 vs APG 1.2 Coverage

mck: Jon's done some awesome work. Jon?

jongund: i basically modified the script we use to generate the examples table to go and look at what roles, properities, states we have examples for

<jongund> https://raw.githack.com/w3c/aria-practices/issue1123-roles-properties-states-coverage-report-script/coverage/index.html

jongund: this generates 2 lists and 4 tables, provides info for things with 0 examples, with 1 example, and more than one example, and links to each
... these sections etc. repeat for properties and states as well
... they're basic HTML tables, put into /coverage directory for practices, and there's a link to CSV files for the above
... uses a script in the script directory, easy to update the document

jamesn: i think this is awesome, would like to see a way of eliminating some roles from 'no coverage' where we're not planning any examples or deprecated things

mck: yeah, this is great. at some point, we want everything covered, but they don't have to be covered by an example, so i'd like to figure out how to index and track non example coverage
... so maybe in a section or div, where we have an ID that's use by the ToC, maybe we put a data attr like data-role-index or something similar that can help us identify what's covered
... something in metadata, if we don't want to burden the actual document very much
... there are some things which shouldn't be really absent, but we still want to acknowledge

jamesn: right, we should be able to have something for that
... i don't want to see us to have something listed as missing or etc., when there's something we don't plan on or where we say use HTML instead etc.

jemma: now I understand, thanks

mck: yeah, this is all just for us anyway, just to keep things clear

jamesn: we have the table for roles, right? essentially says if there's equivalent HTML semantics, use that instead. So maybe we could take that and base things off that a little

mck: what table?

jamesn: in ARIA practices 1.2

mck: oh, like sec 9 or something? okay, yeah
... yeah, we could pull those into a different list here. that's a good source of info

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

jamesn: it's not everything, but it'll probably help

mck: any ideas for the best way to generate index and coverage information for the non example sections of the document?
... like the sections covering grid and table properties
... it'd be good to point people to, and for our report to say we have guidance for, things that are robust like that

jongund: if we can put markup in the doc, we/people can look for that

mck: data attrs might be one such way
... would we want one data attr with everything all together?

jamesn: no

jongund: in the grid and table properties, there's a table. if something has a table of what's covered...

mck: right but we don't do that everywhere. think about naming and describing. that'd enforce a structure which i'm not sure we want to do

jemma: my preference is just having a narrow scope for this document
... keeping as is to meet our needs rather than adding extraneous info

mck: so we haven't really met where and where we don't have guidance

jongund: well like in grid, all the properties are in code elems, so one easy way might be to have a script look for code elems in the AP doc

mck: but jsut becuase they're mentioned doesn't mean they're explained
... i feel like an index isn't useful if it doesn't point to actual info

jemma: so pointing to design patterns?

mck: or keyboard or naming and guidance, etc etc. our indexes don't refer to those non-pattern areas right now

jemma: a simple way is to just leave it as text, rather than automagically scripting something

mck: well i personally don't want to manually keep it and maintain links etc.

jongund: why don't we try a script that looks for code elems and assoc. H2's, excluding certain areas like readme, landmarks, etc.

mck: so the H3 below those?

jongund: it'd have to be in one of the guidance areas, or require an H3 parent and not in those sections

mck: why ignore landmarks?

jongund: just an example, of what to look for

mck: if you want to try, without adding metadata, glad to have the try. but might be hard to maintain
... i'd rather have something easily determinable

jongund: let me think about it, we'll talk about it next time.

jemma: thanks for working on this Jon

mck: Thanks Jon!

Tab Carousel Example

mck: in case anyone has feedback for jon, let's talk about this

<mck> Link to example: https://raw.githack.com/w3c/aria-practices/issue955-add-tabbed-carousel-example/examples/carousel/carousel-2-tablist.html

mck: the main thing here is testing and making sure that it functions and is styled in an agreed on, appropriate manner
... just like in the other example, captions can be displayed on or below the image
... i think the only difference between this and the other one is the dots that allow directly moving to another slide

jemma: and using arrow keys, yes

mck: one design question - do the individual slides have something that could be considered a title? right now, the accessible labels for the tabs are slide1 etc.
... that's okay, but i'm wondering if we were labeling the regions... do we not have labels on the group elements with the slide role description?

jemma: [reading through code] You're looking for the accname for each slide?

mck: I guess the role description is on the element with the tabpanel role. in the other one it's on the element with role group. since this is a tab list... yeah, it says in the table Slide X of Y.

<jemma> <div class="carousel-item" id="carousel-item-2" role="tabpanel" aria-roledescription="slide" aria-label="2 of 6">

mck: maybe what's different here - are there next and prev buttons?

jemma: no

mck: is that normal?

jemma: well, this is auto rotating... usually there's next and prev buttons.

mck: in these carousels with the dots, i thought they'd also have arrows that can be clicked

jemma: our homepage has next, prev, and pause
... what do you think jamesn?

jamesn: I think those things should be configurable, and as long as we have an example that has them...

mck: we do. but the dots are pretty small right?

jamesn: yeah, but we should have examples that have all sorts of ideas/options, and could be chosen to be activated or not

jemma: it does have a pause/play button though

mck: the screen reader experience is a little different, because the experience as you arrow through the tabs is pretty different than pressing next/prev repeatedly

jemma: [reading live region notes from example link]

mck: oh, it's just not working for me then

jemma: [continuing reading]

<jemma> "When automatic rotation is turned off, the carousel slide content is included in a live region. This makes it easier for screen reader users to scan through the carousel slides. When screen reader users activate a new tab, the new slide content is announced, giving users immediate feedback that helps them determine whether or not to interact with the content. Very importantly, if automatic rotation is turned on, the live regio[CUT]

mck: I see that, and I see it in the code, but i'm not sure why it's not working for me right now. I'll test later on
... any other changes to share with Jon?

jemma: no, but if the live region isn't working as expected...

mck: yeah. but one change is to link the other examples, we can add that to the PR

jemma: so another carousel example reference into this PR?

mck: just a note in the "similar examples include" paragraph

jemma: gotcha

mck: please spend some time testing and reviewing, add comments to PR. the sooner it's reviewed, the sooner can be merged

Combobox ESC key clear current selection

mck: we talked about this once before, but didn't get it minuted or in the issue

<jemma> https://github.com/w3c/aria-practices/issues/1066

github: https://github.com/w3c/aria-practices/issues/1066

mck: the last time we talked about this, it seemed like there was genereal consensus that, by default, ESC should -not- clear content. that's what I recall
... just wanted to make sure I'm remembering right
... Evan Y did note that it clears it in Finder on Mac, but someone else mentioned it clears -focus- on the Mac search. I confirmed this

jemma: is the Search field a combobox?

mck: I'm pretty sure
... In Finder, it doesn't actually say "combobox"
... it says "search text field". maybe it just -looks- like a combobox
... hitting ESC closes the popup and my text is still there, if I hit ESC again, then focus goes back to list view. I'd expect text to be gone in that case
... so maybe it's not a combobox

jemma: right

mck: So examples with Comboboxes?

<jemma> mark: when I tested it with window, first esc collapse the text but does not clear the text

MarkMccarthy: Focus doesn't leave the file explorer combobox unless ESC is pressed twice

mck: let's not model off of OS examples

group: [laughter]

mck: another sort of native one is in browsers' address bars. hitting ESC here collapses it, second press clears it, whaddya know
... That was with Firefox

MarkMccarthy: I see this behavior in Chrome and ChromeEdge too

jemma: so why does this matter?

mck: because we got some feedback this -shouldn't- happen. but it seems like this happens with the -second- press
... so maybe it's an optional behavior. maybe we should modify the pattern so if the listbox is collapsed and the textbox is not empty, pressing esc optionally clears it?

jemma: an option is fine, but we might not want to go deeper
... Other opinions?

mck: maybe I'll propose wording back to the OP that it's optional to clear IF the popup is collapsed
... examples would be address bars in chrome and firefox

jemma: okay, i'll assign to you Matt

Insertion and deletion roles

mck: well, let's table this until next week since we're out of time this week
... and the following items

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/sorted/sorted by then/
Succeeded: s/arrows/arrow keys/
Succeeded: s/they/the/
Present: MarkMccarthy jongund jemma jamesn CurtBellew Dorothy_Bass
Regrets: BryanGaraventa EvanY sarah_higley
Found Scribe: MarkMccarthy
Inferring ScribeNick: MarkMccarthy
Found Date: 13 Aug 2019
People with action items: 

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