Meeting minutes
New Issue Triage
<jaunitageorge1> Anyone going to CSUN?
spectranaut_: #457
… Scott will get to this one later
spectranaut_: #182
… follow-up issue for a PR craig opened
jamesn: need to merge #1860 first
spectranaut_: #1861
… potential deep dive topic
… we’ll agenda for next week
spectranaut_: #455
jcraig: should we call this a reserved role?
jraig: if anyone else has suggestions, should we reserve like we do the video element, or is there a better element in existing ARIA?
sarah_higley: group?
jamesn: it’s an additional role, right?
spectranaut_: we’ll agenda this
New PR Triage
spectranaut_: #183
sarah_higley: this is what we’ve talked about before with step 2c
… I rearranged the words and tested in all browsers
spectranaut_: we need reviewers
spectranaut_: #1862
sarah_higley: we might want to agenda this
… it’s been a while since we’ve discussed
<jamesn> "Busy
<jamesn> When others mention you, assign you, or request your review, GitHub will let them know that you have limited availability."
sarah_higley: we don’t have standard deprecation text
… if we wanted to add a process for deprecating things, beyond what we have
spectranaut_: would you create an issue for deprecation process?
jamesn: don’t necessarily need to go through formal deprecation steps for every change
jamesn: with specs being evergreen nowadays, what does it mean?
jamesn: need clarity from management
spectranaut_: it sounds like we should have some consistency in the way we deprecate things
jcraig: it complicates the way things are validated
jcraig: a validator should be able to say it’s been deprecated vs. invalid
jamesn: where the current usage is causing _harm_, then deprecation is perhaps not enough
sarah_higley: it makes it worse here because it’s the wrong pattern
spectranaut_: should we have a follow-up about deprecation process?
spectranaut_: #1860
jcraig: John Gunderson started a few years ago and I picked it up
jcraig: there were some merge conflicts
jcraig: I added some reviewers
jcraig: I opened this as a new PR and closed the old one
spectranaut_: #456
… this was a broken reference to HTML
… asked for Scott’s review. It changes at least Chrome‘s implementation
… not sure what Webkit does — could you take a look, jcraig?
… whether a header and footer should be considered landmark if they’re contained within a section context
spectranaut_: #1859
… pkra already looked at this
… anyone want to review?
sarah_higley: I think this can just be merged
jcraig: I agree
spectranaut_: great, please approve the PR
Deep Dive planning
spectranaut_: do we have any to plan? other than potential process ones
jcraig: if we do a process one, then the expectations for issue and PR templates could be part of that
spectranaut_: let’s talk about it next meeting, and then plan a deep dive if necessary
F2F planning: Seattle or SF, Week of 17 April, 24 April, or May 1
spectranaut_: we’re going to send out a poll, but wanted some initial thoughts
… Seattle and San Francisco had the same level of preference
… weeks of April 17, April 24, or May 1 are the three options
… group preference is for April over May
Add explanations for how textboxes and searchboxes obtain their values
<chlane> https://
<chlane> Otherwise, the value of the combobox is represented by its descendant elements and can be determined using the same method used to compute the name of a button from its descendant content.
spectranaut_: this is an old PR from chlane, wasn’t sure how to resolve
… this PR copies the text from combobox into textbox and search box
chlane: there are comments that need discussion
chlane: observed that “button” is being used confusingly in the spec language
chlane: the dependency here is how buttons get their name
jamesn: it’s specifically calling out an ARIA button, right?
spectranaut_: value is what we’re trying to define here
cyns: would it be better to just take out the button, if it’s only meant to serve as an example?
sarah_higley: should this actually be in accname?
… because there’s a step with a list of steps for how to calculate value
… and it needs improvement
… we should document the steps more clearly there
jcraig: so that’s remove this sentence from this PR, and then file a new issue for accname?
sarah_higley: yeah, and then this point in the ARIA spec would reference that
jcraig: for this PR, there’s already some text that cross-references to accname, so you could imitate that
jcraig: but I agree, maybe value needs to be part of it
jcraig: so you could just take out the whole button sentence
spectranaut_: under all three: combobox, textbox, searchbox, this PR should be removing mention of the value calculation and referencing accname instead
chlane: okay, I’ll open a new accname issue for that
… to review accname calculation
jamesn: so we’ll probably just remove all those bullets from 2c and then rewrite it so it makes sense?
sarah_higley: yes, that’s what I had in mind?
Draft: aria-actions addition to the ARIA spec
spectranaut_: jcraig put agenda+ on this PR
jcraig: yes, there were a handful of things
jcraig: there were some placeholders in the description that I think are all filled out now
… there’s a lot of boilerplate added to specific roles
… the essential stuff is in the new description area
… I wanted to ask about the content of these
… for the AT experience, you land on a thing with actions, and this allows a user to go through from one main thing to another, rather than hitting a bunch of tabstops in between
… like emails meaning being the main thing, with related actions like archive, delete, etc.
… I’m being specific about this because I want to make sure there’s no mix-up for authors or implementors
… actions could be more than just simple buttons operations, like a checkbox that has a label and a checked/unchecked state
sarah_higley: in the first deep dive, we talked about cases where there could be nested dropdowns or inputs
… where the meaning could be altered by the user changing text
… like a “Snooze for [30 minutes]” feature for a meeting reminder
jamesn: the actions must be _visible_, right?
jcraig: that’s the next requirement
jamesn: if they’re visible, then there shouldn’t be a privacy issue
jamesn: any action that you can activate/toggle with a single click should be allowed
sarah_higley: part of this is that actions are allowed as child roles of the parent, no matter what role they are
… so this originally came up as a case where people nest interactive items *within* an interactive item
… which normally wouldn’t be allowed, but aria-actions could enable it, if we wanted to pursue it
… but I’m okay with narrowing the scope here
jcraig: this is good discussion, I’ll try to capture this in the PR thread
sarah_higley: text inputs relating to the action are one example, a spinbutton number input could be another
jcraig: still need to talk to some more people about the focus & click interactions
sarah_higley: this was the main additional complexity I was thinking about
… but just trying to anticipate it, not propose we support it necessarily
jcraig: I think these notes in the PR cover everything, so I can yield time for the rest of the meeting
1.3 blocking issues
spectranaut_: since we almost have 1.2 published, we can soon follow with 1.3
jamesn: I need to close the CFC as well, so I’ll send out an email that it passed
sarah_higley: if anyone wants to review the descendant PR, please do
spectranaut_: in the next 8 minutes, let’s all review PRs
jamesn: please put the link in IRC?
<sarah_higley> w3c/