<zcorpan> https://bocoup.com/blog/how-to-scribe-at-tpac

<zcorpan> might help :)

<scribe> scribe: sarah_higley

matt: reminder, no meeting next week, we'll meet on December 3rd

Tabbed Carousel

matt: this is one of the bigger changes, we're in a good position to land once 1.2 is done
... we want to revisit here and make sure we have the reviews we need
... I'm assigned to the editorial review, Carolyn is assigned to functional review
... it would be really nice if we were able to merge this before the xmas holidays
... we don't have anyone assigned to visual design review, Zoe is assigned to the accessibility review
... Sarah on code, and Valerie on test

zoe: I can do both visual and accessibility review
... I have an alternate visual example, I can have it ready to look at by December 7th

matt: what Zoe's doing wouldn't change the functionality, javascript, html, or testing

zoe: it will probably change the HTML, but not javascript

(correction: December 2nd, not 7th)

matt: functional review and test review can go forward

ARIA 1.2 combobox

matt: for 1.2, there's two primary goals: the first is to close all open combobox bugs
... and then it would be good to add an example of a combobox that opens a dialog, and Jon has exactly that with the datepicker combo
... he has some work to do before it's ready for review, so the PR is not ready yet
... let's look at the combobox project and open bugs, and see how to address those

link: https://github.com/w3c/aria-practices/projects/7#card-28909395

matt: first: extending guidance for combobox to use searchbox role.
... this might no longer apply

<jongund> https://github.com/w3c/aria-practices/issues/1164

returning to tabbed carousel: Jon is asking issue #1164, handling focus moving to tab panel

jon: our current tab panel and regression tests include that requirement, but there is some debate as to whether that's a sometimes thing or always thing

zoe: I think the confusion with the tabbed carousel comes from the fact that you can tab to the panel, but also the anchor that's inside of it
... and the anchor is the same width and height as the tabpanel itself, which is confusing. So we should either remove the link and add that later as an enhancement, or remove the tabindex of the tabpanel itself
... because there's already a focusable element inside of it that encompasses all the content, so one of them has to go

jon: from my perspective, if I tab into the tab panel and it doesn't tell me I'm in a tabpanel, is that confusing? Will the screen reader announce existence of tabpanel if it doesn't receive focus

matt: this is a screen reader dependent thing, and depends on how you're navigating. If you're using the tab key, no screen readers announce leaving the tab panel
... the purpose of putting focus on the tabpanel itself is so a screen reader user could start reading through the whole panel from the top, so it's a good way to place the screen reader cursor at the top
... in this particular case, I don't think we revised our guidance

carolyn: so are we never going to advocate that tab panel is a single tab stop widget?

matt: the tab panel is a container that could have multiple tab stops within it

carolyn: we would never say that you should down arrow to get to the panel?

matt: right

carolyn: just checking

matt: you could put anything in a tab panel, it's a generic container, just like a group/region/article
... there was someone who suggested adding key strokes for putting focus on the tab panel. Those are interesting ideas, but don't have any native equivalent when it comes to tabbed interfaces, and there's no way to convey the availability of those key strokes

zoe: if all screen readers supported aria controls, that would do it
... that is part of the tab pattern

matt: the problem is the screen reader would need to provide a key that works in forms/focus mode

carolyn: or a new aria attribute, that's a new aria-key (laughs)

siri: if I am in a tab widget, when I listen to the tab, if it is placed in a section with aria-label then I know I am inside that
... then if I navigate there and select anything with enter, I know it is selected and focus is sent to the tab panel. And if the tab panel has a heading that matches the corresponding tab, then I know I am in the tab panel
... then I can move focus or use arrow keys, and read the tab panel. Then the next tab is send to the tablist or next focusable item
... as far as I know, only JAWS will say if I am in a tabpanel, and announce the end of the tabpanel. Haven't heard NVDA announce any information about that

matt: that's correct, NVDA does not tell the boundaries of a tabpanel
... I don't think that should influence our guidance too much

zoe: I think we can solve this by making JAWS free

matt: back to the carousel itself, the carousel has two elements that provide focus to roughly the same content. So the question is, whether or not it should be option
... there are two ways to go with that: remove the link focus, which doesn't seem good for regular keyboard users. Maybe it doesn't make a difference if you fake it
... have enter on the tabpanel activate the link
... no, that doesn't help a screen reader user, because they'll never press enter on a tabpanel to activate a link. I take it back
... so, it feels like this is a situation where focusing on the tabpanel isn't something we should do, and the guidance for focusing on the tabpanel should accomodate situations like this. That's my gut reaction

jon: yeah, I think that guidance has to be in there so we can explain in the example
... maybe if the first element in the tabpanel is focusable, you don't need to put tabindex on the tabpanel

matt: that's kind of the direction I'm thinking. I think we already have language sort of like that, I'm looking for that in 3.23

siri: if we keep focus on the tabpanel and we label it, a screen reader user will know if they're in the tabpanel or not. If there's a heading, that's fine

matt: I actually don't see any language in the keyboard section about this
... yeah, we have nothing in the pattern right now at all. Is that what issue 1164 is saying, that we have nothing in the pattern but we have examples that do this?
... the thing is to add language to the pattern to explain when you should do this. It seems that the tabbed carousel is one where you should not do it

jon: and the thing is when the first element is focusable

matt: if the first element is focusable and interactive, then you would not do that (focus the panel), but if the first element was non-interactive, like a heading
... if you want to draft something Jon, that would be great. This is for section 3.23

(tablist)

matt: this would be language that would go in the keyboard interaction section, and corresponding bullet in the states and properties to say it has tabindex="-1". Or maybe not?
... actually, I don't think we usually tell people that

carolyn: we tell tabindex. In each example, the section is states and properties and tabindex

matt: I'm talking about in the pattern, not the example page

jon: we also have a note in there that talks about tab issues

matt: yeah, this would just go in the keyboard interaction section of the tabs pattern, section 3.23

jon: so I'll take the tabindex off the panel in the carousel, then

matt: and also update the carousel test

(back to combobox)

matt: we were looking at the combobox project, going to reorder issues
... closing issue about searchbox with a comment
... the next one: must have a label problem

carolyn: it's "escape key must not clear current input"

matt: this issue is high priority, right? I think we agree we want to change this in all the comboboxes so it doesn't clear the input when you press escape to close the popup
... there's also the optional behavior to clear the input if the popup is already closed

carolyn: we could put it on only one example, to show both

matt: so outside of APG in the real world, is this a thing that people see?

carolyn: I've also seen where escape key will restore the previous value, even after the dropdown is closed
... if I overwrite the url bar in Chrome, and press escape, it will restore the previous value

sarah: there are some places in Windows desktop apps that clear the value, but it's inconsistent

matt: so should we include that (restoring the previous value) as an option in the text?

sarah: I'd rather not -- if people want to, they can, but we shouldn't float it as a possibility

matt: if we have one combo with the escape behavior, how about grid?

jon: I can take that one

matt: yeah, just make it so it doesn't clear when closing the popup
... when you hit escape, it should just close that popup if it's open. That's it
... and one line of change in the documentation below
... next, issue #982, issue with onBlur. Does that still exist after the fixes last week?

sarah: I can take that, check if it repros, and fix if so

carolyn: the person who opened the issue, offered a PR, we should encourage that behavior

matt: in this particular case, I want to get a fix sooner
... yeah, if this is reproducable, this is a high priority
... next issue: authoring practices should specify blur behavior

sarah: so I think I understand this one: it's whether the currently highlighted option is selected on blur, or if selection returns to the previously selected option

<jongund> I have to leave a little early

matt: we already do this, with the different types of autocomplete. This says the documentation doesn't specify it, I guess then it doesn't specify it clearly enough
... this seems like an editorial issue

sarah: I was just writing about this, so it's top of mind. I think it's not super clear from the docs how autocomplete affects blur

matt: we don't have this in the keyboard interaction section but we do have it in the introduction, so I guess this is something we could improve
... this would be part of the section that details interaction when the dropdown is open
... so if you tab into the states combobox and you type "AL" and alabama is highlighted and selected, then if you tab out, alabama becomes the value
... so it does affect the keyboard interaction subsections
... there's five subsections, doesn't apply to dialog
... will figure out specifics later
... next issue: visual design review. Simon, how much of this is left open?

issue 1263

simon: I think I fixed the first three examples, and didn't address the grid example. The grid has color contrast issues at least

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

matt: this is higher priority than the previous issue
... clicking outside the popup doesn't close the popup

sarah: I can take that one

matt: next one, grid combobox: https://github.com/w3c/aria-practices/issues/1266. It seems like the scrolling issues in the grid combobox are pretty bad, I think this should be higher priority

carolyn: I did find it odd that you could type down arrow. I suppose in some search boxes, you can't type down arrow

sarah: oh I remember this, it's actually a bit different, not a blocking problem, just unexpected. This isn't high priority

matt: I'll edit this issue
... I want to skip to the incorrect selection, utah vs. wyoming: https://github.com/w3c/aria-practices/issues/1268

carolyn: I got this twice, the first time I ignored it, but then I got it twice
... hard to reproduce, one time it happened after going back to another window and returning. I can't repro consistently though

sarah: I kind of want to just refactor combobox

matt: maybe if that happens, this would just go away? :D

carolyn: yeah, perhaps this is related to something else too, so maybe we'll wait on this

aria-live guidance

matt: Simon is working on this next week, and we need guidance added to this PR

<zcorpan> https://github.com/w3c/aria-practices/pulls?q=is%3Apr+is%3Aopen+label%3A%22Needs+Review%22

simon: there's a label for open PRs that need review
... these PRs I want to wrap up the week after thanksgiving

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)

Present: Matt_King zcorpan carmacleod sarah_higley CurtBellew ZoeBijl siri jongund
Found Scribe: sarah_higley
Inferring ScribeNick: sarah_higley

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