Meeting minutes
Setup and Review Agenda
https://
Matt_King: Next meeting: March 4
Matt_King: Any requests for change to agenda?
Matt_King: Hearing none, we'll stick with the agenda as published
Publication planning
mk: We need more time for the next publication, especially considering CSUN (which I will be attending). So I've moved this milestone to March 25
mk: Any concerns about moving that out?
howard-e: It works for me
mk: We'll leave it at that, then--for now, at least
PR 3194 - Missing symbol in grid and table properties practice
github: w3c/
mk: Adam_Page provided feedback, and we decided to wait to see if the pull request author would respond
mk: It seems we haven't received a response, yet
mk: It would be nice to merge this, though
mk: If it's possible to push a commit to this branch with the change that addresses Adam_Page's feedback, that would be ideal
Adam_Page: I can give it a shot
Issue 3232 - rowgroup for table body
github: w3c/
mk: We discussed this before. Both Kurt and I did some testing, and most recently, the reporter reported that they can't reproduce the issue
mk: The "role=none" makes these elements extraneous.
mk: Because of that, they kind of work against the APG's goal to keep examples as simple and as pedagogical as possible
mk: I don't think we want to suggest to anyone that there is any value in having those "rowgroup" divs
mk: So, first question is: is everyone good with calling this a bug (and marking it as a "P3" priority)?
Adam_Page: Sounds good to me
mk: I should probably label this as a good first issue
Issue 3237 - Potential bug: incorrect menu structure in navigation menubar example
github: w3c/
mk: The reporter is saying that we have menus with descendants that are menus. That would be incorrect because a menu should be either standalone or inside a menu item
mk: I'd like someone to look at whether or not this is only happening in this one example
mk: I guess this menu has a different structure than our other examples
Adam_Page: I'm comparing "tuition" and "admissions" (because the reporter specifically called those out) with comparable items in the other items (eg. "facts" and "about"), and I'm not seeing any difference
mk: I'm wondering if this is also a problem with the editor menu bar
Adam_Page: We discussed this in last week's ARIA Working Group call. We might want to sit tight while Giacomo follows up on the related spec changes
Adam_Page: In the APG issue, he writes pretty emphatically that it violates the spec. But in last week's ARIA WG call, he posed it as a question, saying that the spec seems unclear on this topic
Adam_Page: If a menu cannot nest another menu, how can we do nested menus at all? A menu item also does not permit a nested menu...
mk: It doesn't?
Adam_Page: I'm scrolling through the ARIA spec of the different roles... Ah, I may be misreading
mk: In our example, the elements with role "menu" are actually linked
Adam_Page: The menus are "ul" elements and setting the "role" attribute to "menu"
mk: So when we have a sub-menu, it is a "ul" contained within the "li" that contains the parent menu item
mk: ...but the parent menu item isn't the "li"; it's the anchor.
mk: To change this, you would actually have to make the "li" the parent menu item, right?
Adam_Page: I'm not sure
mk: If something is a parent menu item, and if it had to contain the menu--if that's the way it's supposed to work...
mk: I suppose it could own it. We could use "aria-owns", right?
Adam_Page: I suppose so. The ARIA spec is confusing about this right now because I don't see any affordance for nesting menus
mk: I guess we wouldn't be able to use links for the parent menu item. Instead of having "li" with "role=none", that would probably be the parent item. It would take a menu, which would be on the "ul" element
Adam_Page: I'm not sure how I would do this, anymore. Though I don't have much experience working with the "menu" and "menuitem" roles
Adam_Page: I'm inclined to let Giacomo clarify the spec since that appears to be an outstanding issue
mk: I actually remember Brian talking about this, but you don't really need the menus to be descendants of... I wonder if there really is alignment on this
Adam_Page: In th spec, there's an explicit section for "allowed child roles" and "menu" is definitely absent
Adam_Page: But I don't see anywhere else in the spec that allows for nested menus, so I don't know how it should be achieved
mk: There's a practical challenge here in that there are probably a lot of menus written in the way that this one is written
mk: so clearly, it at least can work
Adam_Page: This relates to w3c/
mk: And that doesn't have a pull request, yet
Adam_Page: I think he just volunteered to take it last week
mk: I'm fine with us just watching for now
mk: I guess when he submits that pull request, he could hopefully reference this issue. That would cause it to float back up to the top of our list
mk: I'm hesitant to call this a bug because I'm curious to see what kind of feedback Giacomo's pull request will receive
mk: I thought that might be straightforward, but it wasn't!
Issue 3244 - Change naming guidance for radio group, grid, table, dialog
github: w3c/
mk: I guess this issue could end up having multiple sub-issues--one for each pattern that needs to change
mk: I haven't reviewed all of these to know how many changes might be driven by this
Adam_Page: They asked me to raise this in APG during last week's ARIA call
Adam_Page: I haven't looked too deeply, yet--just at three pattern pages. All three imply that a name is needed, but it's kind of an editorial question
Adam_Page: I don't know if it's on us to encourage any of these patterns to have these names because everyone admits that those are kind of narrow use cases
mk: Yes, we do avoid the normative language entirely and intentionally
mk: the way we handle this editorially is there is one thing we've done in the naming practice--the accessible names and descriptions practice page
mk: We have a table of guidance for every role, and we do distinguish "required" versus "recommended"
Adam_Page: That's very severe language that may not be true for much longer
mk: It's okay to get ahead of that pull request and land a change before it is merged
mk: In the patterns, we do use the word "optional" sometimes.
mk: Mike Gower [sp?] has a pull request related to "tab". I was reviewing that and I decided I need to review other examples to find appropriate wording for consistency
mk: I'm trying to figure out which practice we have previously established, here. I think the right thing to do would be to describe that in this issue
mk: Sometimes, we add notes where we try to specify what's important about the naming
mk: I guess, for this, one person could take it on. I'm not going to put my name on this issue, yet, but I will help spec it out
mk: Hopefully we'll be able to find someone else to work on it
mk: I'm labeling as "required for ARIA spec"
mk: We don't know the timeline for merging that, do we?
Adam_Page: Oh! It's already merged!
Adam_Page: It was merged just one hour ago
mk: Ah, I guess we have to prioritize this, then
Adam_Page: Scott also filed a follow-up issue with IBM's equal-access checker to encourage them to remove the associated test
mk: I'm going to label this "P1"
mk: Because this merged, it goes into the editor's draft. Actually--did we change ARIA? Is it evergreen? Will that change go to TR?
Adam_Page: I don't know. I wish Daniel were here to answer that question
mk: We don't want APG to be out of sync. I kind of wish it wasn't merged until we had aligned on a timeline
mk: ARIA changes this, but it would be really nice if someone from the ARIA Working Group would do the merge, here
mk: Well, for now, I've marked this as "P1"
Adam_Page: We could place a disclaimer at the top of affected pages to give warning about a breaking change in the ARIA spec
mk: I think that would be a whole new can of worms
Adam_Page: Yeah...
Issue 3175 - aria-selected requirements in listbox
github: w3c/
mk: so, here's the thing: jaws-test provided an excellent answer to this issue
mk: If I'm understanding this right, this was to specify aria-selected=false in all the items that are not selected
mk: In our example, we don't set an item to "selected" until there is a selected value. This whole thing is about if you have a listbox where nothing is marked as selected--neither true nor false
mk: Is it the case in our example that, once you select something and unselect something, then the selected status isn't persistent?
Adam_Page: Our example does that; I just verified
Adam_Page: Selection persists after you blur away
mk: I think the referenced best practice is not applicable because we do mark something as selected once it becomes selected. And if there's nothing selected when the page loads, then that's an okay default state
mk: This particular listbox doesn't give you an option to unselect. Once you've selected a value, there's no way to deselect entirely--you can only change to a different item
mk: It's sort of like how you can't uncheck a radio button
mk: So I don't necessarily see that as a problem
Adam_Page: I agree
Adam_Page: The issue that jaws-test linked to about a best practice is still an open issue
mk: There's a comment about a second thing. I guess that could be raised as a separate issue
Adam_Page: It's that the "class" attribute does show up on elements with no value. This is kind of a code hygiene issue. Certainly not related to the issue they've raised here