Meeting minutes
New Issue Triage
Valerie: From James Craig about computed role
JC: We made a change that host language may be account for these reserved roles with the intention of allowing testing things like computed role for HTML video. It will return HTML-Video. But that oculd only bve returned by the implementation
… This is for Scott or someone who can write a PR to icorporate that
Valerie: Is it the idea to add a computed role?
JC: Yes, mainly for testability
Scott: We already have such thing, we just don't have this example
JC: There is a handful of ones that don't currently fit well
Valerie: ARIA 2065 -- I think this issue should just be some more clarification on the tree item role description
Matt; I think it's probably that people want to deal with specifying the level in nested nodes
Stephan: I don't understand the issue. You have to use the group but the group cannot change the level. If you want to change the level you'd put the level in the treeitem
Matt: It's not a problem, just an interesting question. I think this needs agenda. It's a big mapping issue
Valerie: Added agenda
Valerie: ARIA 1064
JC: There is also a related one. We need role computation algorithm
… For some rule if it does not have a name it invalidates some other rules. There are conflicting rules and it's not clear which takes precedence
Valerie: Sounds like a larger issue
Valerie: AccName 211
Scott: We talked about this in the editor's meeting as well
Valerie: Was someone assigned specifically. to remove details?
Scott: This should not be in details either. The hidden part is a known issue. The unambiguity is not
JC: Not clear what needs to be hidden. Conflicts with our most recent discussions
Valerie: I'll add agenda, can't remember what the solution was
JC: There isn't one
JC: It's possible we may want to add aria-hidden project if there's not one already
Valerie: I hear you
Valerie: AccName 210
JC: I assigned it to myself, feel free to milestone itit
Valerie: AccName 209
… It's failing in all implementations. All agree that the spec is ambiguous in the opposite way that I interpreted
Valerie: Maybe someone from AccName should read it. Bryan?
Bryan: Yes, I will
JC: Maybe the implementations are what the spec intended. If Bryan agrees we can make an editorial changes
Bryan: Can you clarify on the GitHub issue?
Valerie: I'll add a comment and I'll mention you
Valerie: A bunch of Core-AAM editorial issues that we don't need to discuss here. Thanks James for raising these
New PR Triage
Valerie: A new definition for focusable in ARIA. Mario added this.
Mario: A short entry for the concept of focusable
… Just to explain what it is and with a link to the relevant HTML
Valerie: Do you want reviewrs, Scott?
Scott: I think it's probably premature, I just did the work, not ready to merge
JC: Feel free to add me
Valerie: Even so, you can review
Valerie: A couple of updates to Core-AAM from a new contributor
… We should get reviewers
Valerie: Also on Core-AAM, aria-haspopup mappings. I can review, we need another person
Francis: I can do it
JC: You can add me as well
Daniel: I'll double check that you're on the right team Francis
Valerie: Core-AAM @@@ Notifications
JC: This has been wrong for at least three years
Valerie: Rahim fixed to the wrong reference from text alternative to alternative text
JC: Authors should not be using such definitive terms, especially in an evergreen spec
Matt: But the language has to be definitive at the time it's written
… IF there is not mapping at the time, what would have you written?
JC: I'd just left it blank
… Even TBD is better than no mapping
Matt: No mapping I think is really useful information
JC: I don't think Geko and Chrome engineers look atCore-AAM to figure out what APIs there are in the platform, but just to resolve ambiguities.
Valerie: If there is a change on the language of these specs, they are just documenting the APIs and we need to talk about that. Can you open an issue?
Daniel: I could take a look
WPT Open PRs
JC: Do you think it's useful to include Core-AAM manuals?
JC: I pulled the Core-AAM label out of this, it's only two issues without that label
… IF you are able to review these two, I think these are now ready to go
… This is all what remains from P1
Deep Dive planning
Valerie: Anything right now?
… Let's keep in mind that rest of agenda may end up as Deep Dive
JC: One of the tasks for next year INterop project is that we need an accessibility object associated. It may be worthy to discuss which these would be appart from the obvious ones
… This could also happen offline
… For example, why do you need to have a group if there is already an aria-level? Is there a stack pointer that takes care of nested levels?
… Rahim and I can talk about it
Can we remove this standing issue: Discussion tracking for ARIA Notification proposal
Valerie: I wonder what next steps are for the aria-notifications proposal
… We have now a dedicated git repo but I don't see what has been done
Scott: I'm not driving this. As it's not part or ARIA any more, I don't think there is much I can do
Consider allowing combobox to open menus
Valerie: ARIA 2050
Scott: Thiss has been brought up because people they have what initially aperas like a list of options. Then they perform actions like search or the like. There''s a lot going on about the OpenUI select proposal. The intent was to create a new select element. The current one has a lot of parsing issues that don''t allow for these requirements
… People generally want to create menus out of selects
… They don't understand why this cannot be currently done
… Sometimes that gets mapped to menuitem, others to check boxes. Different ATs treat these differently
… Some people I tested it with did not notice the difference but they were able to discern the options they needed to select from
… Is there a reason that combo boxes don't allow for menu pop-ups?
Matt: I remember specific individuals that didn't like the list of pop-ups that we originally proposed in 1.1
… Originally it was just edit field and list box
… There was a lot of pressure to keep the list of allowed things as small as we possibly could
… I am not sure how you would express multi values in a multi value container
… There are a few things mixed together in this issue. IF it was just the title, that wouldn't be a problem since it would be faitly straightforward
<jcraig> w3c/
JC: This is related to another HTML-AAM issue
… We don't actually expose the default select as list box but as a pop-up button
<Zakim> jcraig, you wanted to mention this is related to the platform-specific presentation issue
JC: We did not discuss this on TPAC as I was not sure how to progress on this, we can join these two issues
Scott: I am not particularly looking for shortcomings. People seem to like how it's done in mac OS
… The platforms went different ways for the same control, interoperability is difficult
JC: I think we can get clsoed to a point where it's usable
… Permissiveness to some degree would help ifwe want shortcomings.
Scott: To Matt's comments, I want to verify that what you said in the other issue is true for menuitem checkbox
Matt: Go to notepad andd open format and then select wordwrap
… I have been noticing more inconsistency lately
… If you press escape that's undo. If there is a menu that doesn't close, I am not sure if the escape undoes what I did or just closes the menu
JC: It is expected on the mac that it both clloses it and it cancels whatever you did in the menu. Because this is not standard in all web components, that's not consistent
Matt: Sometimes I don't always remember
JC: It is a much higher cognitive load for screen reader users
Mario: The menus are for use the same as Matt said. I think it's the same in all desktop applications, why should it be totally different on the Web?
JC: Because attention to detail is more difficult. People who use frameworks rewrite their functionality
Scott: Or this is a designer's decission
Matt: Sometimes space checks but doesn't close and then Enter checks and closes
<siri> Space Enter Activates menu item, causing action to be executed, e.g., bold text, change font. Escape Closes submenu. Moves focus to parent menubar item.
Matt: I do understand from a design perspective that pressing \enter checks and closes. You could not press Enter to close because that would uncheck it
Scott: That's a whole other issue
JC: Menus have always operated on what was clicked and then close. That has been an established UI pattern since the early 1980s
Scott: Do we want to allow combo boxes to open menus? Do we want to make issues related to this subtopics?
Matt: Not sure if that should include multiselect menus
Scott: That's if we can identify a goupr as being multiselectable
Matt: I am happy to own it and go for it as long as it is constrained to what's currently in the title
Valerie: I'm assigning Matt to this issue
Scot: I'll create a separate issue based on discussion
Matt: We should put 2024 unless theer are some implementation issues
<giacomo-petri> https://
Giacommo: These complex scenarios even if we manage them in a proper way from a semantic perspective, they might be quite challenging for keyboard users to understand how to operate with the widget
… You don't know if the menu is closed, if there's multiple options, etc
Scott: There are menuitem check boxes, they have the same hints from screen readers
Giacommo: Semantically they are, visually they might be challenging
Matt: We do have keyboard guidance
… The choice in the toolbar we had to go with menuitemradio. It works , but it works differently than regular radios. They don't change automatically to selected when navigating them
Scott: This is a broader issue. Sometimes things look differently than how they're exposed and that's OK