Meeting minutes
<Jem_> https://
Setup and Review Agenda
Jem_: Any requests for change to agenda?
https://
Jem_: Next meeting: April 29
Jem_: Hearing no requests, we'll stick with the agenda as planned
Publication planning
<Jem_> https://
Jem_: This is tracked with Milestone #41
PR 2991: Add Practice Page for Supporting Color Contrast Settings by mcking65
github: w3c/
Matt_King: We had a review from Joe, who suggested some changes
Matt_King: And this morning, jongund pushed a commit
jongund: Yeah, I've been re-organizing the heading structure based on those suggestions
jongund: I'm going to work on updating some of the content, too. We've been missing a section for testing
jongund: So this is in-progress
jongund: I'll send an e-mail to the list when this is ready
Matt_King: Sounds like good progress! Thank you!
PR 3387: Developing a Keyboard Interface Practice: Clarify guidance for “Focusability of disabled controls” by adampage
github: w3c/
Matt_King: This turned out to be not so simple! Small, but not simple
Matt_King: I made two small suggestions
Adam: And I made commits this morning to accept those changes and to merge in the main development branch
Adam: Merging in the main development branch didn't address the problem, though. The linter continues to complain about a link that is returning a 403 error
Adam: The links are to a Firefox plugin that I believe jongund wrote
jongund: Ah, there's a better URL for that project. It's to a more stable page that I control
Matt_King: Could you file a new pull request for that?
jongund: Sure; which page is this on?
Adam: I've just now tagged you on the comment that describes the issue
Matt_King: So this one is ready to merge. Daniel can you take a look and let us know if we're aligned?
Daniel: I reviewed quickly already, so I think this is fine. I'll leave a comment
PR 3400: Revise Content for New Experimental Example of Scrollable Listbox with Actions on Options by mcking65
github: w3c/
Matt_King: I think we'll skip this for now because Curt isn't present today
PR 3418: Landmark Practice: Update alignment between HTML aside element and ARIA complementary role by NakajimaTakuya
github: w3c/
Matt_King: The last time we discussed this, jongund had review it, but he hadn't actually looked at whether or not the content changes were aligned with the HTML-AAM.
Matt_King: Last time we talked about this, we talked about some potential bugs in Firefox--but that isn't relevant to the pull request
Matt_King: What's relevant is whether the text correctly reflects the HTML-AAM, so I think this still needs your review, jongund
Jem_: Joe is also marked as a reviewer, so we should nudge Joe
Matt_King: Daniel is also listed as a reviewer
Daniel: Ah, yes, now I remember. On the WAI website, we have an implementation that just uses summary and details that operates like an accordion
Matt_King: That was a different issue, actually.
Matt_King: This issue is related to the "aside" element and how our guidance doesn't currently reflect recent changes to the AAM. The author has proposed change that he believes will align our guidance
Daniel: I have been speaking with Valerie to add this to the ARIA group's agenda on Thursday
Matt_King: Okay, thanks for doing that. That's good
PR 3421: AlertDialog Pattern: Add guidance about use of `aria-modal` attribute by NakajimaTakuya
github: w3c/
Matt_King: I've done a review on this, so before I we talk about this, we should give Joe a chance to review
skipTo.js update
jongund: There is no pull request for this, yet, but I'm currently fielding a request to make the link visible on mobile
Matt_King: That's interesting. You might want to propose the change and then have people review that.
jongund: Alright!
PR 3434: Accordion Pattern: Remove optional arrow, home, and end keys
github: w3c/
Matt_King: This originates from our discussion from the previous meeting on March 31
Matt_King: This also has one very minor editorial change. It's not part of the issue, but I decided to include it because it's so minor
Matt_King: I think given the size of this change, just one reviewer should be adequate
jongund: I can review
Matt_King: Okay, I will assign you
Matt_King: I've added this to the publication plan for May, so that's the time-frame we're on
Matt_King: Thank you, jongund
Issue 2438: Tablist that supports reflow
github: w3c/
Matt_King: This is on the agenda because there is someone commenting that they're trying to work on tabs for a design system, and they want to make sure that their "tabs" component supports reflow
Matt_King: The questions that they are asking in recent comments are from March 11 (I wish we had this on our previous agenda)
Matt_King: We made sort of what I'll call a "high-level" or "not very concrete" proposal for a solution in this issue. One that suggests that there could be a menu button that allow people to open a menu where they could choose from additional tabs that could be displayed
Matt_King: So if you only have room to display, say, three tabs, then you could use the menu button to choose which tab is the third tab
Matt_King: There are a lot of questions about how this should work. I think there are both design questions (which the APG does not need to be opinionated about) and accessibility question (where the APG should offer some guidance)
Matt_King: I think we have learned from experience that whenever there are tricky questions like this, the only way we end up with real answers is to attempt to do it ourselves
Jem_: Yes. Creating an example raises so many important questions
<Zakim> Adam, you wanted to mention https://
Adam: The aria-actions example I made a while back does support reflow. It's not the most elegant solution (it just stacks the tabs), but it conforms
Adam: When I began developing that aria-actions example, I started with the tablist as an example, but I noticed that they don't support reflow, so I added support for that
Adam: The tabs become vertically stacked. They really just reflow like any other inline element. The tabs themselves wrap
Matt_King: What happens to the tabs on the second line if you have a tab on the first line selceted?
Adam: That case is not elegant because the visual link between the tab and the content is broken, but the state is still apparent due to the other visual properties
Matt_King: That is one approach, and maybe we should modify the simpler "tabs" examples to do that
Matt_King: However, I do think there is another common pattern out there that is "prettier" but slightly more complex from the accessibility point of view
Matt_King: I think the thing that's always held us back is that you can't place a button in a tab list
Matt_King: But if we had the tablist element reference it... I don't know how legitimate that would be, though
<Jem_> This design is common Example 1 – Fluent UI: Tablist with Overflow
<Jem_> https://
Adam: We don't strictly need aria-actions to address this
Matt_King: The commenter describes adding a menu button that acts like a tab
Matt_King: It's not a great experience because it's called a tab but it's not a tab
Matt_King: Others just put a menu button in the tab list, but that fails conformance checkers
Matt_King: There's a "Trick" for this [describes trick]
Adam: Oof, I don't know if we want to describe a solution that we wouldn't recommend in the real world...
Adam: We could do something at the edges to show the availability of additional options
Matt_King: A tiny bit like a carousel
Adam: Exactly
jongund: We have to consider what they are building. They are building a tab where the things are in a list. We should have an example that demonstrates that because that's what people are doing
Matt_King: The only problem is that ARIA doesn't give you a way to make that
jongund: But it's just styling. I don't see any change to the code other than CSS styling
Matt_King: Maybe I don't understand what you're suggesting, then
jongund: In the example the commenter is pointing to, they make the horizontal tab vertical. Instead of hilighting beneath the tab, they hilight to the left of the tab.
jongund: My guess is that is a pretty common thing that people do
jongund: We should have an example that demonstrates that. Maybe one that changes from a vertical list to a horizontal list
Matt_King: I understand, now. Would you change the arrow key binding, as well?
Matt_King: And change aria-orientation?
jongund: Is it valid on a tab list?
Matt_King: Yes
jongund: then we should add that
Matt_King: We have notes about the keyboard interaction in the pattern, as well
Jem_: I know the use case. You have so many tabs, and there is no affordance that you have ten tabs. That's why people have a "More..." tab
Jem_: In Adam's example, he can have 10 tabs, and he can stack them across the viewport
jongund: In the example here, they have a button to reveal the additional tabs
Matt_King: We have four approaches: the crude wrapping approach (which Adam implemented), the horizontal scrolling (as Adam suggested), the switch to vertical, and the "more..." button (which is technically most complex)
jongund: Do we have to have a "more" button? Do the users have to know that there's more available?
Matt_King: Yeah, you have to make your touch and your keyboard aligned with one another
jongund: How would that affect touch?
Matt_King: If you're scrolling through your tabs with touch, you would have to double-tap the "More..." link to access the additional tabs
Matt_King: That corresponds to an additional interaction. It would be really confusing if you had to do it one way with touch and another way with keyboard
Matt_King: On mobile, I switch between touch and keyboard all the time
Matt_King: Okay, so there are there these four approaches
Matt_King: We have two simple tab examples now: one with automatic selection and one with manual selection
Matt_King: We could demonstrate horizontal scrolling and vertical scrolling very easily by choosing to do one example with one and the other with with other
Matt_King: Adam is saying that it's not realistic to use aria-actions for this
Adam: Well, people have done it in real life. It's not terrible, but it's not great, either
Matt_King: Maybe it's something for the future, then
jongund: When you choose one of the items in the pop-up menu, it changes the ones that are visible. The final one becomes the selected one
Matt_King: Right, that's common
Matt_King: I'm just saying there are some really thorny questions with the "More..." button approach
Matt_King: For instance, when it comes to the placement of the button, especially considering conformance with ARIA
Matt_King: I just think the ARIA spec doesn't address the "More..." button approach. That makes it difficult to discuss in the APG, so I think we need to file an issue with ARIA as a start
Adam: That's why I like the simple reflow approach because it satisfies the specs
jongund: Will anyone use it in the real world, though?
Adam: Yes, people use it all the time
Matt_King: I think it would be a good thing to demonstrate that in our examples
Matt_King: Is there an advantage for mouse button users? Is it hard to scroll those?
jongund: what about the toolbar pattern? Does it change to a toolbar if you do what they're talking about here?
Matt_King: Well, you can't place tabs in a toolbar?
jongund: Right, but maybe the tabs are now a list of disclosure buttons
Matt_King: I don't think that would fly in the real world. I don't see people changing their tablists to toolbars
CurtBellew: At Oracle, we have three of these implementations. Or at least two of them. One is the "scrolling list". For AT users, you go through each, and it feels like a long list. For a visual user, it fits in a frame, and you have a button you can click that will cycling through the options.
Adam: My suggestion also includes visual buttons to assist the scrolling (rather than just presenting a scrollable area)
CurtBellew: Right, ours too, actually
Matt_King: The keyboard user doesn't use them, so they wouldn't be in the tab order. Does the touch user need them, though?
Adam: Yes, and that makes this solution a double-edges sword. It can be inconsistent for different users. That's why I've generally avoided explicit scroll assistant buttons
CurtBellew: I think for our implementation, they check if it's mobile, then they don't show the buttons (users can only swipe to reveal more items)
Adam: I've seen bad implementations where there is no indication that the tabs can scroll. If the tabs are arranged "just so" it's easy to be tricked into thinking that there are actually no additional tabs at all
Matt_King: I guess the availability of scrolling "helper" buttons is a complicated thing from an accessibility point of view. That would be a reason for APG to illustrate it. But then again, a reason NOT to illustrate it is if we believe it is unrealistic or overcomplicated
Adam: I'd vote "no" for the scroller buttons
Matt_King: It sounds like we should do both. The number of options here is growing...
Matt_King: Maybe we should just focus on the horizontal scrolling and have one that has the buttons and one that does not. Then people can compare that
Matt_King: ...and then LATER, we can consider adding further examples that contemplate switching to vertical layouts
Matt_King: We could have two people work on this. I think that would be cool because it could inspire different ideas. Someone on the "automatic activation" could do without the scroller button. And then the one on the "manual activation" could include the scroller buttons
Adam: I like that
Matt_King: That could be two separate pull requests
<Jem_> Mike: Fifth examplae - a fading pardigm
Matt_King: I was assuming that scrolling without helper buttons would do that.
Matt_King: But it sounds like I shouldn't have assumed that
Adam: Big "plus one" to jugglinmike's suggestion. We either use a "fade" effect or a "drop shadow" which also indicates overflow
Matt_King: Is either better in terms of supporting high-contrast
Adam: Ooh, wow. I don't know if I've considered high-contrast in this context
Adam: Both of those effects would probably break in high-contrast, honestly. They'd both be wiped out in high-contrast mode...
Matt_King: Okay, that's a pretty interesting question
<CurtBellew> I need to drop off to attend an urgent call. If you all have a chance please take a look at current demo changes in w3c/
<Jem_> Mile:..indicate taht there are additional options without actually presenting interactable UI is to use.
Adam: My hot-take would be to say, "well, there's a scrolling region, so just display the scroll bar". It's an existing UI paradigm for visualizing scroll-ability
Adam: perhaps you could be clever by not rendering the scroll bar outside of high-contrast mode (and just relying on the fading/drop-shadow paradigms, instead)
Adam: this is right up my alley, but I am so busy right now that I can't take it on
Matt_King: James N might be a good candidate for this work
Matt_King: We can use this discussion to create some highly specific requests, and then those could be more approachable by anybody outside of this room
Adam: I agree. They smell like "good first issues" to me
Matt_King: We could create two issues from this issue and make this issue dependent on resolving those two new ones.
Matt_King: Maybe that's the approach to take for now. Maybe even the person who asked the question on March 11 would be interested in helping out
Adam: Yeah. I also wonder if Ari would be interested. This seems like it's in her wheelhouse, if she's available of course