Meeting minutes
New Issue Triage
jamesn: dealt with
Scott: already commented, with think on it some more
jamesn: assigning to Scott
spectranaut_: follow up from accessibility child... assign to me
jamesn: pkra dealt with it
New PR Triage
jamesn: contextual role concept proposal
scotto: needs reviewer, val? html-aam uses "scoped" but not defined... context of accessibility child. Aaron L as a reviewer too. spec out aspects where elements role changes based on context
scotto: proposed header/footer roles
jamesn: agenda+ for next week
scotto: draft PR, will agenda+ it later
<dmontalvo> w3c/
jcraig: needs reviewers, will like implementor bugs and write WPT tests if it looks good
jamesn: scotto and spectranaut_ reviewing
Deep Dive planning
jamesn: virtualization topic may be worthy of deep dive
jcraig: timing conflicts with I/o, gaad, and wwdc
jamesn: none scheduled for next week
Provide a role for file input type
jamesn: Diane from ETSI filed this...
we've made certain things non-global, like aria-invalid
so no way to mark a non-aria role as invalid
jamesn: this is a functional widget that should take invalid
jcraig: I think it seems possible this could work as a aria role. click (IIRC) and drag/drop events can work with file upload
scotto: additional context... Diane posted in ARIA in HTML. I made a PR and waiting on review. aria-invalid and aria-disabled are allowed on native... should be able to use those in a parity role.
input type=color is a special case. can't make it required or invalid.
jamesn: really? makes no sense.
scotto: this issue is interesting though... this did come up in one of the computedrole threads re: input type=*
scotto: could we define this at a higher level so that the aria attrs can cascade to other element where they are not currently allowed, such as aria-invalid on file inputs
cyns: could we have a subclass of input that would be assignable for these attrs?
cyns: invalidity in html is weird re: formatters
scotto: I've done testing related to that
<dmontalvo> James: This is doable. I am wondering if it is necessary though.
<dmontalvo> ... Does she say in there why she can't use a hidden type input file
<dmontalvo> ... If that's reasonable maybe we can add this to aria practices
scotto: her use case was a button element that can't take invalid, delegating the invalid from the file
<dmontalvo> James: That feels like a separate issue or at least a one of several solutions to a related problem
<scotto> w3c/
scotto: I'll take assignment, I have a related issue in html-aam... pls cross ref to HTML-AAM #421
jamesn: seems weird to allow something even though the spec says it can't
jamesn: do we need something in aria countering/complementing this aspect of "host lang attr wins"
jcraig: m. clarification of jn's comment
What to do about the rowgroup discrepancy between the spec and implementations?
<scotto> jcraig: while tbody, thead, tfoot are defined as rowgroup in html aam, they're largely ignored in implementations.
<scotto> jcraig: but the point was raised what happens when these elements are made focusable and need to be exposed with a role?
<scotto> jcraig: seems reasonable to keep the role then, but we want to make sure we dont' do anything that could break AT.
<scotto> sarah_higley: looks like there's no support for role group? but in practice i've seen support?
<scotto> jcraig: you can style it. printing styles have use. but nothing AT related.
<scotto> sarah_higley: uia in edge exposes it
<scotto> jnurthen: it definitely gets mapped if scrollable or focusable
<scotto> jcraig: please post any results you've found in testing.
<scotto> jcraig: agree that it makes sense to map the element if it's focusable. :: shows tests updated to have focusable examples ::
Windows/Mac differences in presentation of some HTML-AAM implicit roles
<scotto> jcraig: the one related to this issue is JAWS Test. I think these are variants of the same issue.
<scotto> scotto: I decided to treat this as one issue.
<scotto> jcraig: this could be a contextual role? we could have a decision tree on how the role should behave with the platform and multiple types of behaviors based on the element used
<scotto> jcraig: the context of the DOM, or the rendered presentation could be relevant here in how it's exposed
<scotto> jnurthen: is there any way to solve this?
<scotto> jcraig: the mapping could be adjusted in the HTML AAM mappings
<scotto> jnurthen: it could be mapped differently based on platforms, which we did before core aam and just referencing the ARIA mapping
<scotto> jcraig: true for file upload too. elements can render differently across platforms
<scotto> jcraig: don't need to solve this on the call. but we can think more on it. not sure if mapping could change. could be a prefixed value instead of a specific ARIA mapping since platforms don't align
<scotto> jnurthen: needs a mapping that attributes can map to, otherwise they could not work
<scotto> jnurthen: could we specify that aria attributes could be allowed on native platform roles?
<scotto> jcraig: i have an issue assigned to myself to indicate something like that in the ARIA spec. Also to indicate that authors should not be using platform mapping roles, e.g., html-video
<scotto> sarah_higley: aria-invalid isn't allowed on button. so even on macOS that wouldn't be allowed
<scotto> jcraig: need to think more on that
scotto: seems reasonable to to address in html-aam in some way... maybe open-ui select proposal
Update from PR #1018 for nameFrom: heading
jcraig: jamesn this is ready for your review along with the prerequisite aria-common script change