Meeting minutes
scribe=
New Issue Triage
spectranaut_: this is the only issue. (523)
<spectranaut_> in html-aam: w3c/
jcraig: there are different behaviours with underspecified areas of the spec. Some balancing between heuristics between layout tables, whether in column or row.
jcraig: link to results from test, Rahim is interested in writing more tests to illustrate further differences. WG needs to decide which behavior is correct.
spectranaut_: Scott could look at this, but he's not on the call. Maybe we should agenda+ when more tests land?
New PR Triage
<jcraig> w3c/
spectranaut_,: first one https://
<jcraig> w3c/
spectranaut_: next. This is ready to review. Is it something in Chrome? Should we add Aaron?
Sarah: Aaron should probably also review.
jcraig: none of these are testable yet. I'll add blocked for that. We'll need new WPT APIs for this. It's not fully specced or landed yet.
spectranaut_: any other reviewers?
Juanita: I can
spectranaut_: be nice to have 1 more if we can.
Siri: you can add me.
spectranaut_: last one is https://
<siri> shirsha
zakin, next item
WPT Open PRs
spectranaut_: no ones?
jcraig: new ones that don't show up because the metadata... if they don't have the accessibility keyword... there are about 4 or 5 open at this point.
jcraig: going through review - there's another PR in `wpt-metadata` repo. Added that so it shows up in the standard search.
spectranaut_: web-platform-tests/
No spring face-to-face this year
<jcraig> web-platform-tests/
spectranaut_: we aren't having a F2F this year, mostly because we didn't have enough time to plan this. James in on vacation for a month, and we've crossed the year boundary so budget requests may be a concern. But it seems no F2F won't be blocking? And we have TPAC in September.
Whitespace for CSS pseudo elements )
spectranaut_: This PR is blocking next stage in publication of Accname. Accname is evergreen... Daniel! My understanding is this is blocking?
dmontalvo: we need to move accname to CR. Related to that, this is blocking us from moving, this PR - the pseudo spacing treatment. It's ambiguous now.
Bryan: Block level/inline elements, not just pseudo elements. Essentially any block/inline level element rendering as such. Pseudo elements rendered in the same away. It boils down to adding spacing around block level and not inline. This was never specified in spec.
jcraig: Bryan is correct, there isn't an open issue wrt inline vs block in this particular PR. The thing I have flagged is the context of referring to spacing in the context of a pseudo element. Inline vs block are all in the DOM and so there's a space between them or not, but pseudo elements are generated by the renderer, and so they're not in the DOM and never will be. There's no concept of whitespace - ASCII or otherwise. The wording... i[CUT]
@jcraig: Inline vs block are all in the DOM and so there's a space between them or not, but pseudo elements are generated by the renderer,
@jcraig: so we could come back or... I wanted to discuss this today. The visual element could have whitespace like a margin, or there could be...
@jcraig: no such thing as spacing between two nodes, as in whitespace characters. I want to make sure everyone is aware of this. It can't be part of spec as it's written.
Bryan: I understand. I don't think it's possible to account for all the cases.
Bryan: if you put display table on there it'll turn into block level element...
jcraig: display table vs display block? It may count as block level in the context of spacing.
Bryan: if its possible to have it as a block level, it shouldn't be concatenated with text, with no differentiation.
<Rahim> block-level = "takes up entire width of a line?"
jcraig: Display property has dozens of values.. it's not something we can reasonably update the spec for
jcraig: I think this would be a reasonable justification for having a CSS AAM. More targeted space for reviews from css editors.
Bryan: if we can move it forward that would be awesome. I'm fine removing the pseudo section to get this moving.
jcraig: Yes we should table it to get CR. I'll take the action to remove those parts.
spectranaut_: we have css-aam repo...
jcraig: we resolved to move the files from css-aam back to aria, and leave that repo just for issues. Perhaps we should move to aria repo before we start?
spectranaut_: let's follow up. I think we need to discuss a little more. The idea to move to a monorepo didn't resolve one of your concerns. Comments are in issue... I'll make an item.
spectranaut_: issue is related to the fact that if you have a PR preview the links between specs won't be accurate, even in a monorepo. Links in spec are generated.
jcraig: a problem with respec?
spectranaut_: I think. It'd take some work to look into.
Proposal for adding ARIA parsing rules
spectranaut_: Rahim proposed this originally.
Rahim: this was raised around ambiguous nesting of headings, in strange ways. James observed nesting aria headings, trying to do a robust heading structure. But it made me think there should be parity between html & aria parsing requirements.
Rahim: for example a link in a button isn't valid html, nor should a link in role=button.
Rahim: so I raised this to try to get clarity on how aria should be "parsed", if there are rules that we can specify to facilitate this.
jcraig: Valid HTML, a div with role=heading, aria-level=3, followed by a nested <a> with role=heading aria-level=3, followed by an h2. This is all valid HTML.
jcraig: How to resolve? core-aam related to host language associations? I'm not sure how to resolve it.
<melsumner> didn't we talk about this a few weeks ago?
spectranaut_: where is this specified in HTML?
<spectranaut_> melsumner: just in triage
Rahim: the parsing rules themselves?
Rahim: they're part of HTML itself, button for example is a certain type of content and can't have other content in it. Button nested in link, fails parsing, but ARIA equivalent seems to pass.
Rahim: these were the ones that came to mind for this issue.
jcraig: ARIA is purposefully permissive to allow for some corrections, e.g. if something can't be valid HTML, but webdev can render it, then whoever is making it accessible should be allowed to make it work as intented.
jcraig: there are places where we don't want 1-1 mapping with links. I don't know of a11y... is there a link inside of a button? Maybe we shouldn't have that?
jcraig: we should have some rules at least.
jcraig: does a link in a button work?
Rahim: it works from mouse keyboard perspective but from AT it'll announce "link, button".
<melsumner> strong disagree
jcraig: if there's nothing preventing it from being used by a sighted user we shouldn't disallow for AT.
<melsumner> on allowing nested interactives to work just because they work for a sighted user.
jcraig: if a span=role button with a nested span role=link would work, with event handlers you could make those work. If HTML allows different renderings, this is exactly what aria is for.
<melsumner> It messes up the accessible name, among other things
Bryan: How does this stuff work with role=presentation?
jcraig: exactly.
jcraig: so HTML element continuation would split the button into two descrete buttons and the link would exist as a sibling between them.
Rahim: so are we creating expectations, or parsing rules?
jcraig: I'm just trying to explain how we should err on the side of the author doing something funky.
Bryan: I saw this a while ago with an online shopping site, a role=button, within that a button and link to go to the product page, to go to the product. It caused so many issues -
Bryan: 1 you couldnt identify what was in the button. You could use JAWS virtual cursor but had similar issues. It was basically unusable from AT perspective.
jcraig: Thats a problem, unexpected markup _is_ the problem. The solution would be code changes to major engines, and potentially AT - when we discover a weird pattern, write some parsing rules so for e.g. nested headings, the outside one wins.
jcraig: for button/link - we could expose as a link separate from button. So screen readers do know how to handle that.
giacomo-petri: there are scenarios for example nested links, which is parsing issue. Rendered as 2 consecutative links, but using JS you can inject a link in a link. What's the expectation for ARIA here?
jcraig: Thats a great example. Could you please add that to the issue?
Rahim: one thing comes to mind is WCAG 4.1.1; WCAG 2.2. what constitutes a parsing failure? WCAG2.2 has a note... curious if that gives us greater impetus to resolve this?
spectranaut_: might be nice to link to that in the issue too.
<melsumner> Rahim, here's a good article: https://
<Rahim> WCAG 2.2 SC 4.1.1 Parsing note: https://
melsumner: I'm a little surprised. We seem to cycle back around to nested interactives. So far we've considered them author errors, and we shouldn't do anything about it. I kind of agree with Rahim, perhaps we need more clarity. Nested interactives are awful. When you use AT or SR the accessible name is all messed up
melsumner: all the link text gets shoved together. It's confusing. I don't think we should fix or allow this. Strongly opposed. We should work with HTML.. you can't nest interactive elements, stop doing that.
melsumner: sometimes we get strange issues, "what should we do with users". Clearly we need to help with developers. I don't think we should make it so their weird code works.
<spectranaut_> keithamus_: I have a couple points, WHATWG was trying to handle nested elements in the summary element. the discussions are happening there, and some cross pollination should happen. priority of users, if the pain is there for the user, we should fixed ahead of developers
<Zakim> jcraig, you wanted to say... I'm not proposing this is not an author error. I think Rahim is proposing we write implementation rules for how to account for the error consistently between browsers.
jcraig: to melsumner's point. I do still think this is an author error. What I propose is there are rules to account for specific patterns of author error. This is how the engine should consistently account for that.
jcraig: the goal isn't to allow authors to do this, but if it's working for the mainstream user interface we should make that work as well as possible for AT use case.
Rahim: yes I am proposing the same. Nested interactives is one, but improper landmark usage - nesting inappropriately, radio role being contextual.
Rahim: what happens if I have custom radio buttons without explicit grouping. Invalidation error?
Rahim: I see multiple cases where we should determine what is correct for aria.
<melsumner> Thanks for clarifying, jcraig :thumbsup:
StefanS: landmark structures are okay if they are part of a dialog in the page? e.g. a banner in a dialog? Is that okay?
jcraig: the scenario I'm hoping to avoid is a web page with valid HTML, working in an inaccessible way. If an a11y dev comes on to insert ARIA in a way that makes the markup accessible, but is now not valid, that discourages the author from making it accessible.
jcraig: so "author error" is maybe a warning, not an error.
jcraig: the way to fix is probably to change the markup. I don't want new parsing errors discouraging authors from making their page accessible.
StefanS: validators, we have. The problem is it disallows a banner within a dialog within a page that has a banner. But if the dialog is modal this is okay. So two banners cannot be on the page at the same time, but there are no good lookup tables to document these.
Rahim: That's an interesting example. Dialogs being indexed content, being searchable in a search engine - when you activate the link, it takes you to the dialog page. It's not the main content, it's a dialog. It's almost like a trend where dialogs have their own h1, own title, treated as a separate page.
Rahim: indexable, searchable, separate. It almost sounds like we would have to consider them pages.
<melsumner> It makes sense StefanS, because _to the user_ either the page exists or the dialog exists. So from that perspective, it should be okay that there is a header/role="banner" on both.
spectranaut_: this issue still feels explorarity. Do we want more examples?
spectranaut_: next steps or ideas?
Rahim: I can add more context, might warrant a deep dive?
spectranaut_: great, could you add the deep-dive tag once more context is added, and we can arrange it?
Happy to but I don't recall how
Is that it?