Meeting minutes
New Issue Triage
jamesn: #1883 - no need to talk about
… #1882, ditto
… #1881
<annevk> Could someone share the meeting passcode with me?
scottohara: let’s lump this in with live region topic
jamesn: we’ll do it at F2F
<jamesn> https://
<annevk> Works, but audio issues. Will retry.
jamesn: #1879 — this is a F2F topic
ARIAMixin has many integer attributes with string types and uses DOMString? incorrectly - w/ @annevk
jamesn: annevk, can you take us through this issue?
annevk: currently the HTML spec has an assert that the attributes need to be enumerated, but the ARIA spec does not define them as enumerated
… normally, IDL attributes reflect what the attribute should actually be, like boolean and number types
… we need to fix the type issue. DOMString? doesn’t work
… a lot of the ARIA attributes could be turned into HTML-style enumerated attributes
… many do allow N string values, etc.
… the way enumerated attributes work when you restrict them to known values is that if you use getter with an unknown value, it will return the last previously known value
… currently, it’s hard to feature-test new values for these attributes
<annevk> https://
annevk: my proposal is to go through all the attributes, especially the string-based ones, and try to figure out how they could be defined in terms of HTML’s types
… a lot of it is kind of an editorial change
jamesn: the enumerated attributes and unknown values — it could be a problem to do that
… it’s already defined what should happen when unknown values are encountered, and it’s not the same as you described
annevk: presumably it maps to a _a_ state of some kind?
jamesn: I think it’s meant to be the “unknown” value, but with booleans it’s different
… for others, it’s “not present”
… but it’s never the “previously known” value
annevk: IDL has a “missing” default value and an “invalid” default value
jcraig: for background, if you have markup `aria-label="foo"`, in this context we’d call that a “content attribute”
… we have a fairly arbitrary distinction of states vs properties
… from an editorial perspective, we’ve begun trying to refer to these more generally as attributes
… the benefits of annevk’s proposal is that making these changes, especially now that we have web platform tests, will allow better testability between engines, feature testing
… the potential con is that there is some risk of interoperability problems
… e.g., Salesforce has a polyfill that ties into these DOM properties
… this would change some of the behavior that could break their internal framework
… we do need to work out the problem of different default values for different types
Matt_King: are there ways of making this change without breaking Salesforce, by allowing user agent to respond in _either_ way?
jcraig: we kind of have precedent for that with class name and class list
… in IDL class name has simple string reflection
… then we said we’d like an easier accessor, so we made class list
… so we could always add _new_ properties for cases like this, but it can be messy
annevk: it would increase the complexity a lot
Matt_King: does it give us a path toward graceful degradation?
jcraig: if we were to go this route, both props would probably exist in perpetuity
jamesn: at the moment, what we have is at least consistent within ARIA attributes. Is there a risk that in trying to become more consistent with the rest of the web, we become internally inconsistent?
jcraig: the question to the group is: are there any objections to this proposal? If not, then annevk can finish up the PR
… and we’d have some more review going forward
jamesn: wasn’t one of the initial objections was the problem of default value? And that engines themselves didn’t want to put new logic in for that?
annevk: I recall that coming up for computed values, but that’s not necessarily what’s at hand here with just defaults
jamesn: we need to run this by Alice
jamesn: if we were to go forward, should we just take the pain of breaking things?
jcraig: annevk reminded us that Gecko does not implement this yet
jamesn: people should know where polyfills exist and dig into the apps that have them
jamesn: what’s the action going forward?
… it sounds like we have an affirmative consensus, is that true? Any objections to annevk doing more work on this?
<Matt_King> +1 for compatibility with wider web
jcraig: let’s loop in aaronlev and Benjamin to make sure other implementors are on board
jamesn: sounds like there’s a way forward, and we can review the proposal again when it‘s further along
annevk: the gist (https://
<jamesn> https://
jamesn: check out “Author error states and properties” in the spec
annevk: for the `role` attribute, we can’t remove values that are not supported, we’d end up reflecting string as-is
jamesn: yes, `role` clearly has to be a string
jcraig: thanks for all the work, annevk
jamesn: please work with me or pkra as you work on the PR, if you need help with any of the language
annevk: I’ll either create a draft PR or an issue with questions
New PR Triage
jamesn: #463
… scotto, is this ready for review?
scotto: yes, this needs review. Picking up threads from a long time ago about mappings that weren’t reflected accurately
… with us deciding not to map contenteditable to role="group" in the minimum role discussion
… this change should largely just reflect reality; nothing normative
jamesn: #1880
scotto: this is agenda’d already
jamesn: let’s add some more reviewers
scotto: this definitely needs some wording updates
F2F planning
jamesn: thank you to people who’ve added F2F items
… please keep adding so we can put our agenda together
jcraig: it’s possible that the one I added might need 2 sections
… good for me to give an overview of what’s changed in WPT
… and then earlier/later in the weeks, we could have an overlap session
Step 2C includes controls with value that are directly referenced by labelledby or describedby
jamesn: #186 is merged, so this one is unblocked
spectranaut_: this doesn’t have the PR checklist
… we should copy that in to prepare for merge
aria-hidden error case: disallow aria-hidden on root or document element (e.g. <html> or <body>) agendabot]
scotto: axe-core, for instance, already has an author check for no aria-hidden on body
… next step for the PR is to make sure all the language makes sense
jcraig: since we have some implementers here, we can finalize some of the terms
… do we want this to apply to nested root elements?
… e.g., <html> inside an iframe in side an ad banner
… there are some cases where it could break, but some cases where it could be used helpfully?
jamesn: is there a plan to allow aria-hidden on <body> versus the root document?
scotto: I didn’t consider the iframe scenario
… if someone wants the content of the iframe to be aria-hidden, it should be on the iframe, not on its inner elements
jcraig: we should leave the “Author MUST NOT” for now, but can change if someone reveals a compelling use case. The more important one is “User agents SHOULD”