Meeting minutes
Setup and Review Agenda
https://
Matt_King: Any requests for change to agenda?
Matt_King: Hearing none, we'll stick with the agenda as planned
Matt_King: Next meeting: February 18
Publication planning
Matt_King: We'll decide whether any of these new issues or PRs will be added to the plan. But as of this moment, you can find everything we have committed to in the milestone referenced from the agenda
Matt_King: The next publication is scheduled for February 25
Matt_King: That's two weeks from today
PR 2991 - Practice Page for Supporting color settings
github: w3c/
Matt_King: Several people have looked at this, and it has changed a fair amount based on their reviews
Matt_King: There is new content that jongunderson added within the last week--change which I have not reviewed from an editorial perspective, yet.
Matt_King: But I still think it would be good to have more people to review before next week
Matt_King: To look for both editorial and accuracy problems of any kind
Matt_King: Adam_Page is the only person to submit a formal review so far--thank you, Adam_Page
Adam_Page: And I can look again in the next week
CurtBellew: I'd like to take a crack at this, too
Matt_King: It would be great if you could get to it before next week's meeting
Matt_King: There's a lot of content here, so I expect we'll be revising it until just a few days before publication
Matt_King: But I get the feeling that this is already in a very high-value state
PR 3214 - Multi-thumb slider fix
github: w3c/
Matt_King: This only touched one file
arigilmore: This was a pretty simple change. It was looking normal locally, but on the live website, it was slightly off. I took the suggestion on the issue (making sure that, at minimum, it is displaying the correct value, and using the existing math otherwise)
Matt_King: So this will not effect any of the tests
Matt_King: Does this need to be reviewed on multiple devices? On mobile and laptop?
arigilmore: That would be a good idea
Adam_Page: I can take a look at this one, too
Matt_King: Thank you, Adam_Page!
Adam_Page: I'll look at it on one mobile platform and one desktop platform
Issue 3232 - rowgroup for table body
github: w3c/
Matt_King: It's not clear to me how much of a problem this is in practice
Matt_King: Apparently, our table example (where we build a table from divs and spans in order to illustrate the "table" role) uses the "rowgroup" role to represent the table body
Matt_King: The reporter is saying that none of the browsers map it that way
Matt_King: This seems like a problematic mapping in the first place.
Matt_King: The reporter says that neither NVDA nor JAWS can navigate by cell when this is done...
Matt_King: They provided a link to the HTML
CurtBellew: I'm assuming that it's pointing to the table example. If you look there, that example does use "rowgroup". I'm not sure I understand because I tried it with JAWS just to see if I could navigate using table navigation. So either I'm doing it differently or I'm not understanding the concern
Matt_King: So the table example is a table that has, like, "students", "first name", "last name", etc... I am able to navigate this with the JAWS table commands (alt + ctrl + left, right, up and down)
Matt_King: And then "alt+ctrl+end" does go to column 1 row five
Matt_King: I don't see that there's necessarily a functional problem here--at least not with JAWS
Matt_King: If we took out the divs that have "rowgroup" on them, it really wouldn't change anything, I don't think...
Matt_King: Looking at the HTML, there are two different rowgroups--one with one row (for the header), and one with the other three or four rows (with the body). But it's just a div with "role=rowgroup". I don't think it can do anything. It's not as though the one for the head is different from the one for the body.
Matt_King: Maybe we shouldn't have included them
CurtBellew: I took a quick spin with NVDA, and it was basically telling me that I wasn't in a table
Matt_King: Oh yeah. "Not in a table cell" is what NVDA says
Matt_King: Ah, but that's only when you're in the head row
Matt_King: It seems to think that essentially the first row in the body is the first row in the table
Matt_King: That gives me reason to think that if we got rid of the rowgroups, it would treat all the rows the same
CurtBellew: I'm going to a really simple WebAIM table, and I'm not able to get out of the table, there. This is very strange
Matt_King: The reporter links to HTML-AAM issue #474
Matt_King: But this is going in the other direction. It's like when some of the browsers are taking thead, etc and translating them into "role=none". That's Chrome and WebKit which are doing that...
Matt_King: Should we take out the "rowgroup"s
arigilmore: I don't know! I don't think I have enough understanding on this one
Adam_Page: Ditto for me; I'd want to look into it more
CurtBellew: My initial thought is that I don't understand enough about why we implemented "rowgroup"s. For me, it seems logical that we could just remove them, but without knowing more of the history, I'm not so sure
Matt_King: From an accessibility point of view, I don't know what value these roles add
Matt_King: That's why this person is requesting their removal
Matt_King: Maybe CurtBellew can do some testing. If we can remove all the roles without impacting the behavior, then I think we should definitely remove them
CurtBellew: I'll do that testing and report back
PR 3216 - Landmark pattern changes
github: w3c/
Matt_King: I think we'll skip this for now because jongunderson isn't here today
Issue 3217 - Proposal for accessing context menu in trees
github: w3c/
Matt_King: Right now, normally, to get to context menus with the keyboard, you would have to press shift+f10, but on Macs--I actually don't know how to do it on Macs if you're not a VoiceOver user.
Matt_King: There might not even be a way to get to context menus with the keyboard if you're not a VoiceOver user
Matt_King: To require shift+f10 on a Mac creates an unusual discovery problem
Matt_King: But if there's an icon that's to the right of the tree node, then perhaps you could use the right arrow
Matt_King: Is the icon traditionally on the right? It would be very strange if it was on the left and you pressed the "right" arrow to access it!
Matt_King: I'm looking at a Windows one. It makes sense that, on an open parent node, the right arrow would move to the first child. But it is, as they point out, redundant because as soon as you press right-arrow again, it doesn't go to the next sibling; it goes nowhere. You have to switch to using down-arrow
Matt_King: It is a little interesting that in order to get to the context menu for a parent node, you would have to first expand it, and then you would be able to get to the context menu. Which I guess is fine as long as expanding doesn't have any side-effects...
Matt_King: But I guess that's more of an "app design" issue
<Jem> w3c/
Jem: The ARIA spec does not provide information about the way to determine how many items caused the menu to open.
Jem: Is there something here that we can resolve within ARIA instead of within our practice pages?
Matt_King: Well, I think this actually--this present proposal is not about the structure of the nodes or the DOM. It's about the keyboard interaction specifically
Matt_King: The way that they have worded the proposal, though, it sounds like they are thinking that the context menu button would be a child, I guess of the tree item.
Matt_King: The way it's written in the proposal, though, it seems like it would have to be more clear
Matt_King: I don't think there's any down side to this idea (that I can see)...
Matt_King: So, we had talked about making another ARIA-Actions example using tree. At one time, Adam_Page had suggested that he might be open to working on that
Adam_Page: Yes, I think I did, and I think I would still be. I'm working on a separate thing which came up last week (Scott's expandable region)
Matt_King: Oh, right
Matt_King: One question I had is: in the case of a tree, would it be fairly common for there to not just be one button for context sections, but for there to be a whole collection or row of buttons (separate buttons for, say, "delete" or "move up" or "move down" or "rename")?
Jem: One design I observed was state medicare app. They were struggling with the design--that you could remove one line and at the same time add a line and edit it. One line had different options
Matt_King: Lately, I've seen more resistance to adding a menu button which people have to click to learn what the actions are. Designers seem to be preferring to display all the available actions so they can be readily reviewed
Matt_King: What should our feedback here?
Matt_King: Does anyone see any reason they shouldn't be using the right arrow to explore additional actions?
Jem: Can you explain "node"?
Matt_King: A node is a tree item. You have root nodes, parent nodes, and end nodes... But they're all just tree items
Matt_King: Think of an "<li>" with "role=tree" on it. That could have, inside of it, the name of the tree item as well as several buttons. Those buttons might only be shown visually when there's hover or focus on that item
Jem: What is the relationship between one item with different options? I know it might hold it as context, but there's no "owned" or "parent"...?
Matt_King: The relationship would be "aria-actions". The "<li>" would have aria-actions
Jem: Ah, right, that's why we came up with aria-actions
Jem: Do we ask Mike to come up with a draft?
Matt_King: He did include some potential revisions to the arrow key language in this issue. The thing that I would suggest to change is that I don't know if we would want to use the term "child item" because it could be misconstrued as as another tree item
Matt_King: I think that by "first child", he means "child that represents the context action"
Matt_King: The use of the word "child" in the description is a little problematic because I'm not sure what "child" represents
Jem: Can we use the aria-action concept here?
Matt_King: Yeah, I think that's what the intent is
Matt_King: I can write a comment to ask for some additional clarity