Meeting minutes
New Issue Triage
spectranaut_: we've got one from dmontalvo
dmontalvo: yes, patrt of it seems to work now will continue teesting
spectranaut_: next one is aria/2411
spectranaut_: it's on editors agenda
spectranaut_: next one is html-aam/573
spectranaut_: from Rahim. This is moving along the goal to have CSS AAM information
Rahim: now woulld be a good time to start adding guidance in there
Rahim: we've been working on this
scott: to add to that, anybody who's got anything to add to the plan Rahim put together, feel free to add to this
New PR Triage
spectranaut_: only one that we talked about next
WPT Open PRs
spectranaut_: I think James Craig already taook a look at most of these.
spectranaut_: first one, web-platform-tests #50045 is related to the first item on agenda for today
spectranaut_: #50004 is related to content visibility, will talk about at the deep dive next week
giacomo-petri: I added a summary of what browsers are currently doing
spectranaut_: anyone interested, feel free to review before deep dive
Deep Dive planning - Content Visibility next Thursday, January 23rd
WPT Open PRs
jcraig: did you discuss the one that I mentioned on the ARIA editors slack?
spectranaut_: is it an interop issue?
jcraig: was a new issue on WPT that I wanted some feedback on from scott, melanie, and bryan
Deep Dive planning - Content Visibility next Thursday, January 23rd
spectranaut_: we'll have a deep dive in the hour before this meeting next week
spectranaut_: are there other deep dives anyone wants to schedule?
spectranaut_: sounds like not
Rejoin working group if you haven't already
spectranaut_: this is a reminder to rejoin the working group
spectranaut_: seems most have done that
Matt_King: it's not the individuals but the organisations?
dmontalvo: first the organisation/AC they nominate and then you can rejoin
dmontalvo: and IEs rejoin
lola: as an IE, when I tried to rejoin it didn't seem to work
dmontalvo: I can check with you offline, lola, I have to do something manually
Descendants of buttons with "Children Presentational: True"?
spectranaut_: this is an old issue that recently got agenda'd back, scott or aaron do you want to intro tihs?
<spectranaut_> Tests: web-platform-tests/
aaron: Firefox doesn't cut subtrees in buttons
aaron: sometimes people put role=button… a use case I saw was a schedulingblock in a calendar, that was marked as expanded=false, then you can navigate to the button and it expands all the info inside
aaron: bit weird, but I saw it twice. It seems like a bad practice in general to remove content, and then users can't get to stuff
aaron: better for us to leave it down to the screenreader. So that it's more of an authoring req to have presentational children than a UA req
matt_king: do you mean authors go in and mark role presenttation?
aaron: would be that we won't have interactive children inside of a button
Matt_King: I think we have that already?
aaron: I'm not very strict about this… I think it needs to be enforced on authoring tools layer
spectranaut_: do you want to describe test you wrote giacomo-petri ?
giacomo-petri: I added an example with an HTML button where I injected an inner button within the outer button. The first one doesn't have conflict because both buttons are not focusable because they are divs with role=button
giacomo-petri: in the second one, it's native HTML buttons, focusable by default, triggers the resolution for presentational roles
giacomo-petri: should be exposed as a button role even if inside another button
giacomo-petri: does that make sense?
jcraig: to me yes as I reviewed it. I did add ac omment re readability of the test
jcraig: not sure if results are product of the test or of a bug
sarah: we talked about this idea of having a content model type spec, with phrasing content first and other things like aria actions… would that make sense here to get rid of children presentational? I hear the idea this works in browsers, but wouldn't say it actually works-works
sarah: eg a heading would be announced as 'heading,button'… if you have a button in a button would you even know it's a button if everything is announced as one?
Matt_King: I'm thinking a lot about parents… there's a tension between two scenarios. The people approach. When people code something and it sortof works and people don't know it's only sortof, they don't get a signal from what's exposed to them in the accessibility tree or tools they use
Matt_King: feels like a tension between being able to give enough signal that what you've done is lousy but kind of works vs that you've actually done something good and it does work
scott: to address what Matt and Sarah said… if we looked at this as a repair, and stronger author guidance…maybe that's a good way to split the difference
scott: I've talked to Aaron about this a number of time… obviously it is better to expose something than nothing if authors have done the wrong thing. Not-ideal is better than completely blocked
scott: but to Sarah and Matt's points… people do make mistakes in practice. If we could update the spec to note that this is absolutely an author error, people shouldn't do this, but that browsers may mitigate the author error
Matt_King: but authors probably won't look at the spec, can't browsers add errors?
scott: browsers do have console errors, and tools like axe-core can find and flag these things
scott: checkers define this
Matt_King: does it do anything in the accessibility tree view in the browsers?
Matt_King: seems like that's one of the only places people look
scott: don't think browsers do anything right now to say anything is wrong
Aaron: I think Edge does
Aaron: it puts red squigly llines in the DOM view if there's a11y errors
Aaron: we're going to try and convince the Chrome dev tools to include something like htat
Aaron: something jcraig mentioned once, if something is invisible for screenreaders, it shouldn't render for visual folks either
Matt_King: would be great
aaron: but ARIA doesn't affect pixels (visible rendering in browsers)
aaronlev: there should be some way of handling the use case I mentioned, not sure what it is. Like an expandable reason that actsl ike a button
aaronlev: it's like a region that the Enter key can toggle
Matt_King: you need something focusable or discernable for that
aaronlev: our job is to make it possible for people to make it accessible
Matt_King: there's something that indicates to a mouse user that it can be clicked?
scott: I think there's probably something that can be done… but probably not our job, to Aaron's point, to tell people what to do exactly
scott: not sure if it should go in APG but we can add it somewhere
jcraig: everytime Matt and I talked about this over the years, it reminds me the original argument was XHTML vs HTML… if you used XHTML with strict rendering, the entire page wouldn't load, which I'd say is one of the main reasons XHTML failed
<aaronlev> jcraig: you were looking for the word draconian :)
jcraig: we can't control it such that something that doesn't work for AT users also doesn't work for visual users
jcraig: doesn't fit with priority of constituencies, would make authors frustrated
jcraig: I think there's lots of opportunities to flag issues to authors. But preventing from working is something W3C gave up on a 1,5 decade ago
pkra: to get a better understanding of the pattern Aaron was describing… the region that can be expanded upon clicking?
aaronlev: I think scott played with it more … I understand we need JAWS to work with it but NVDA worked kind of okay?
bryan: re the parent role… I've seen this quite a bit over the past few years… like on one site there was a shopping cart , a web region that had a bunch of buttons like increment and decrement
bryan: especially in virtual cursor view, there is no point to have a button, is there a way to negate the effect of the parent role and simply ignore it?
Matt_King: I think we should ask that question, Bryan. As you were describing the scenario… I had the same thought
Matt_King: I wanted to clarify to jcraig, am not asking for anything… in HTML it's easy for anybody to make a mistake in the code that causes the page to not work properly. Lots of easy mistakes one can make
Matt_King: eg you can leave off a closing quote of an href
Matt_King: I'm not suggesting anything unusual
jcraig: was re if something doesn't work for screenreaders shouldn't work visually either
Matt_King: would make this equal
jcraig: maybe compromise could be some kind of heuristic like the ones we've been adding to various places in recent times
jcraig: as long as we phrase it carefully I'm open to it
Matt_King: agree, I think that's a repair where the heuristics are part of the spec
jcraig: a significant portion of the HTML spec is repair
spectranaut_: are we closer to next steps?
aaronlev: further
aaronlev: I'm saying spec should be updated to reflect reality
spectranaut_: does anyone disagree that spec should follow what majority of browsers do?
bryan: I'd like to see it cancel out the role
spectranaut_: possible resolution couldbe to change spec to match the browser and make sure there is author guidance
scott: I agree with that… understand the reason for these updates. I think if we can add strong author mustnot's, indicate to authors they're not doing the right thing, I'll file an issue with APG to add it there. Not sure what else we can do at this point
Matt_King: I would oppose only changing presentational children, would be insufficient
scott: we'd also add that it's a mustnot
Matt_King: without any other browser req at all?
Matt_King: is there a UA SHOULD requirement that should go in there?
scott: not opposed to that
bryan: one of the issues with this type of control, when you arrow into it, something that says button… same as with skip links… you get insufficient user interactions
Clarify use case for aria-selected for 'grid' role descendants
spectranaut_: this is a new issue from last week
spectranaut_: It's about a way to select columns and rows in a grid. Should we clarify this before we discuss, did anyone read it differently?
spectranaut_: suggestion is aria-column-selected, aria-role-selected
sarah: was supposed to respond, I think this is not a good idea
sarah: if anyone thinks it's not not a good idea, do feel free to share before I respond
Should the 'row' role really be necessary for parents of 'gridcell' and other cell role elements? agendabot]
spectranaut_: this is request that row is not a required parent of grid cell
Matt_King: is there some parallel to this in HTML tables? where you don't need trs?
scott: no
jcraig: can do without row groups
jcraig: this could be another set of repairs… if it's just one row… a grid with three cells
Matt_King: this seems to be about visual presentation not semantics
jcraig: they're talking about CSS grid layouts and media queries
scott: fwiw in the previous discussion there was some discussion of aria-rowindex
jcraig: we're kind of forcing people to remove and append child to different rows and create them on the fly as opposed to changing a few attributes
Matt_King: in tree grids we don't need any kind of row and specify level?
sarah: I tested tree and it works fine without groups… if you sert aria pos set size explicitly. Has anyone tested what happens if you set the indexes for every individual cell?
jcraig: seems like a reasonable request to me
spectranaut_: test cases seems like a reasonable next step?
scott: I engaged before, can reply and ask for test cases
[accname] Explicitly state UAs must ignore “aria-label” for slots
Write tests for input elements supplying name by aria-labelledby
jcraig: I don't think I've seen this use case
scott: it's come up a few times in the past for me
scott: had a thing that was named by something… seems like something that can be worked around
scott: like something that someone could have pointed to with an ID, there's usually a way
jcraig: was also wondering due to update prefs… eg label outside of current document scope
scott: don't see why we wouldn't do this
jcraig: maybe circular ref