Meeting minutes
New Issue Triage
jamesn: first issue is editorial
pkra: let’s discuss now
jamesn: html-aam#575
pkra: can we shorten the URL in the About section in the GH repo sidebar?
pkra: nevermind, just closed issue
jamesn: aria#2415
… I think this falls into html-aam or ARIA in HTML
scott: I’ll take it or agenda it
jamesn: html-aam#574
scott: absolutely going into html-aam to match HTML spec
… but don’t need to agenda this
… just want people to be aware
… opinions? should there be any mappings? please comment in issue
… otherwise I’ll pull over as not mapped
jamesn: aria#2414
… old thing coming back up again
… might have way forward
… judging by the analysis in the issue
Rahim: yes, correct — we met late last year
… to discuss improving ARIA IDL
… one change we discussed is in HTML spec
… for how nullable DOM strings reflect
… ARIA has nullable DOM string
… ARIA spec needs it so we can discern whether attribute is missing versus whether it has a value
… e.g., aria-label
… I’m ready to move forward and will raise a PR
Rahim: thanks all, I’ll get started
jcraig: thanks for this investigation, Rahim
Rahim: this should help us align better with HTML spec
smockle: does this align to one of the proposals we reviewed at TPAC?
Rahim: yes
… we have lots of attributes that can be migrated to enumerated
jcraig: everything Rahim presented has a path forward
… the only thing that was left was that we had nullable DOM strings that weren’t enumerated, but Anne said we can change that in the spec
… this is the most minor change to HTML that allows the entirety of the ARIA spec to align to it
Rahim: one quick question
… there are a number of issues related to IDL
… can I create a single board or project and create subtasks?
… a lot I want to tackle together
jamesn: you can create a project
… there are new-style and old-style projects in GH; it’s a bit confusing
… there used to be a way to get the old projects
keithamus: I’ll see if I can find the old IDL project
jamesn: any more on this topic? or shall we drop from agenda for future?
Rahim: I’ve got everything I need
jamesn: I’ll drop it
New PR Triage
jamesn: aria#2421
… thanks, Rahim. Can merge this
… aria#2420
pkra: this is for accname
… an updated link
jamesn: can we do this without a hardcoded link?
… I’m gonna review this one to see if we can link differently
… aria#2419
Rahim: I’ve been busy ;-)
jamesn: does it need implementations? are there tests?
Rahim: yeah, I think we should write WPT tests
… jcraig raised an issue that markers should contribute to accname
… like a list marker
… so I’ve added a step as part of CSS-generated content
… appending that marker content to the accname
jcraig: I’ll review
BryanGaraventa: I’ll review
scott: me too
jamesn: aria#2418
… since it has a normative SHOULD, it won’t be editorial
… reviewers?
scott: me
Adam_Page: I’ll review
jamesn: aria#2417
… reviewers?
spectranaut_: I’ll review
Adam_Page: me too
jamesn: aria#2416
scott: this PR was assigned to Matt a while ago
… just wanted to get the ball rolling on it
… all I’ve done is mention `menu` in the `aria-haspopup` area
… seems to solve the original issue
… maybe we could provide more for author guidance, but is it necessary?
jamesn: seems like a simple one
… reviewers?
Summer: I’ll review
<Mario> Me too
jamesn: aria#2413
… in draft still
Rahim: we can skip this, still working
jamesn: once it’s ready, please agenda it
Rahim: will do
WPT Open PRs
jamesn: a few new-ish ones. jcraig?
jcraig: think I’m up to date
scott: nothing for me, but I’ll look through
Deep Dive planning
jamesn: any deep dive proposals?
… nothing scheduled
jamesn: want to decide what the editor’s direction is on this
… should we explicitly put Required as False instead of the absence of the Required row?
… we talked about this and think it would be noisy
… so instead, in section 5.2 of the spec
… looking through these, some things are missing
… name required, for example
… so we think this should be updated
… and we can say here “if it is not present, then it is false”, or “... not set”, or whatever’s applicable
scott: I agree with that alternate direction
jamesn: this would be a good first issue
… read through the spec to find all of them, then detail the missing ones
smockle: I’ll take this
jamesn: just read the last comment in aria#2411 for direction
… thanks, smockle
Add Accessible Name Required row to each role's characteristics table where it is missing
[aria] Drop “deprecated on this role” attributes from per-role tables
jamesn: wanted to share editors’ opinion on this
… in 1.2, we moved a number of properties from being global to only being allowed on certain roles
… when we did that, we deprecated rather than removed
… 1) to avoid breaking the web
… 2) eased our implementation
… because states and properties that are non-global applied to something not allowed “MUST not be exposed” according to the spec
… by making this deprecation, browsers MAY still expose them if they want to
… so there would be zero implementation changes needed
… so now we have a request to not make these deprecated anymore and to actually remove them
… as editors, we decided to leave them deprecated for now
… as something that is conforming for browsers, but still discouraged for authors
… still nervous about removing them and consequences down the line
… and there doesnt seem to be precedent in unversioned specs for how to remove things responsibly
… we prefer authors don‘t do this, but we more importantly don’t want to break anything
scott: I agree with not taking the deprecation away
… but wonder if there’s a middle ground
… like HTML’s obsolete section
… at what point could we move stuff like this to an obsolete section
… the problem I run into with conformance checkers
… is that they don’t call out the SHOULD NOTs
… so authors feel more freedom than they should
… we never know how a browser or an AT might expose a problem
… that’s my overall problem with the SHOULD NOT state
… don’t want to let authors get away with sloppiness
jamesn: could that be addressed with a change of language, in terms of how we define “deprecation”
… in these property tables, we could take them out of the main table, and then add a more explicit “Deprecated states and properties”
… don’t know if that would help, or just busywork
<smockle> 1?
smockle: what you just described is similar to what HTML did
… moved deprecated stuff to a collected section
… HTML5 has a differently named but similar “Non-conforming” section
<smockle> https://
<smockle> https://
jamesn: moving to an entirely new section would be complicated for the ARIA spec because of some surrounding language, but it is possbile
<Mario> +1 fot that
scott: don’t know if that’s urgent right now
… but I do like that idea for the future
… since we have other deprecated stuff in ARIA that should be moved
jamesn: roies are potentially easier to move
… maaaaaaaybe
… there are a lot of interdependencies
pkra: let’s discuss in editor’s meeting
Should the 'row' role really be necessary for parents of 'gridcell' and other cell role elements? agendabot]
pkra: a lot of discussion in the issue, as well as some sample Codepens
<jamesn> w3c/
pkra: let’s take a look at these
scott: I haven’t looked at these demos yet, but I think they’re trying to show us markup patterns that we already support
pkra: does anyone want to take this one and deep dive into it?
… let’s tag aardrian and see if he’d be interested in taking it
jamesn: done
… any other comments?
scott: will be interesting to know what the implementation cost would be
… browsers need to create the rows
jamesn: seems like something that would be useful for a bunch of implementations
… I’m gonna leave agenda on this
… it deserves some thought
… will tag aaronlev