Meeting minutes
New Issue Triage
James: distinguish cognitive emotion rich decorative images from purely decorative ones
James: We have some Jon and Sina discussion in the issue
James: my take on this is I don't think this is an ARIA problem, and HTML should solve this if people agree it's a real issue of a way of specifiying a descriptive image
James: Or it's a personalization issue, with the personalization work going into APA, potentially
James: it's a can of worms I don't want to get into, is my general stance
Melanie: I agree, I don't think -- 1. it's a common issue with auditors, they'll just flag it.
James: An auditor in the thread, Sina, is expressing the opposite opinion, that an emotion rich image should have alt text on it
<siri> +1 for the screenreader input in the image
Greta: At the Post we have an idea of -- we call them "live graphics". They are interactive and emotionally deep in the way they present information to the readers, and we always try to give some explation to the users, because it's part of the story we're trying to tell
Scott: FWIW I tend to agree this is something that should be looked at, but it's something that doesn't belong in ARIA
Scott: unless we can mint an aria-mood="angry" out of this, in which case I want to do this
Jory: As far as emotion, like in the example from the Post, there's a difference between how a person reacts to content vs. the intention it's trying to convey. I might have an intention, but the emotional reaction is a reaction and not intrinsic.
Jory: For example, I can show a puppy, but I can't tell you the emotion you should feel is "awww" vs. that you got bitten by a dog when you were younger
James: But the knowledge that a puppy is present should be there, right?
James: We need to do something with this, and I think personalization is the place to send this.
Melanie: sort of like prefers-reduced-motion, we can have prefers-reduced-emotion
Scott: can we just make this meeting making puns about this issue?
James: [stuff about personalization distraction] -- there's a simplification one as well, so maybe if you want simplification, you wouldn't get this. So you would put alt text on this and that it could be simplified
Matt: I guess I wasn't thinking about this, I was thinking about screen reader tone of voice changes
James: the question is what do we do with this. I want to get rid of it, not just punt to 2.0
James: I'd love to move it to the personalization group, I might just address Jon, I think he's involved in that
James: is that OK with everyone?
Stefan: isn't this also a WCAG thing because how to use images and apply descriptions? I see it as the WCAG realm.
James: I think there's a line in WCAG for ones you do want to put alt text on vs. ones you don't, and I don't think it clearly expresses that
James: sure, but this issue here, I don't see sending this to WCAG as being useful
James: because it's asking for something to enable this, rather than changing validation
James: is everyone OK with me moving this to personalization?
(general assent)
New PRs
James: this is a draft PR to move abstract roles and essentially hide the abstract roles
James: this is a POC and not finished
<jamesn> https://
James: what this does right now is adds a button under the categorization of roles section 5.3 with a note that says [reads note]
James: And then all of the consequences of hiding them in the spec. There was a bunch of work that had to be done to any references to the abstract roles that had to be moved. I created a bunch of important terms that took care of most of the abstract roles that were referenced from somewhere else that wasn't another abstract role
James: the definitions aren't good yet, it's meant as a POC to show we can do this
James: so what do people think, is this a bad idea, or good idea to get rid of abstract roles from the spec
Matt: Was this in preference to the other issue where there was a suggestion that we prefix abstract roles?
James: Maybe I missed that one
Matt: it was recent, within the last couple months
James: (reads issue) -- that involves other work, I guess this is an alternative
Matt: I dunno, prefixing sounds simpler and more clear and more useful to me
James: why?
Matt: because I do think that abstract roles are useful in terms of understanding the ontology, so when we say "a menu is a select" or whatever, they are useful phrases
Matt: I understand that you can easily replace that with a definition, but to me it's always been helpful and I know this doesn't get rid of abstract roles, but to me it's always felt like a really useful thing to understand the ontology
James: but that's for us the spec developers, and I don't think we're the important people in this discussion. So if it makes it easier for us, I don't think that matters
Matt: I may have a bias because I work on the spec, but I don't know if I think that way *because* I work on the spec. I think there's a lot of clarity that would be gained from the prefix idea because I think every developer understands the concept of abstract
(scribes note: I don't think every dev understands that :D)
Matt: I think it would add a lot of clarity to how things work, because people would see abstract, and go "oh I understand how this works here", so I think a newcomer to ARIA would get a lot of benefit from hte prefixing concept
James: let's ask, anyone here who's been here less than 5 years?
Sarah: I know they're there and understand them, but I don't get benefit or drawback in daily life
Melanie: we just added a rule in Ember linter around them
James: Does it aid you in having them in the spec?
Melanie: I dunno, I know the HTML spec has a separate one for authors and browser engineers. I think we should step back and do this at a meta level, you should pick your adventure on why you're visiting the spec
James: Our general intention is we encourage authors to look at APG instead of the spec itself, and it's largely intended for browsers and framework devs and folks like that rather than authors
Greta: I was gonna say I never even noticed they were there
Matt: oh wow
Curtis: I always find them kind of educational if I'm trying to understand, but that's about it for me too
Joanie: can I ask a Q in response: if it weren't a role, instead of having value or whatever and we just use a word instead of making it a role, would that lessen your understanding? I"m pretty sure all the UAs have code that includes the roles and says this shouldn't be used
Joanie: why should we have code that handles something that shouldn't be used?
Matt: I've always thought it would be way cooler if it were like an interface concept, like we could have roles that inherit from this interface concept
James: For me, this is starting to sound more than 1.3 as soon as you start talking about control patterns and changing interfaces and stuff like that
Peter: Just to jump back to the impressions -- I remember coming across them and realizing they exist, and I think my only feeling was "why is it the last sentence in the section that says authors must not use?" I read through it and thought I could skip this, but that could be stronger
Peter: when we talk about th eoverview, we still have in the triage to get to the part of the diagram that might help as well in this context
James: OK, I'm hearing very mixed things on this PR, so I think I might just abandon it. So I'm hearing folks don't like this direction and they like abstract roles in the spec
James: it'd be less work if we just but "abstract-" in front of them
* sarah also thinks they could be nuked
James: Joanie wants them nuked, so you don't like my half thing of hiding them?
<pkra> sorry, have to drop off early. bye.
Joanie: I thought it was an improvement. But as long as there are roles, then we need code that handles it, and just whyyyyy
James: could we have wording that just says UAs should ignore this?
Joanie: I've seen code in at least one UA but maybe more than one that says "if you see this role, ignore it"
Joanie: roles that should be used should just not exist in my opinion
James: anyone want to take a stab at doing the alternative approach of prefixing them with abstract and tweaking the language?
Matt: I was thinking about what Melanie and Joanie are saying, and the halfway steps don't necessarily... I guess we need to define the problem, but the halfway solutions don't fully fix them. So if we were to fully get rid of the abstract roles and replace them with a concept -- we wouldn't need to rewrite the whole thing, because the definitions could still fit there
Matt: we could have an inheritance thing like interfaces
James: I'm looking at all the scripting that handles attributes, and I don't want to mess with that
James: I'm hearing no, and I'm wondering if we should just punt this and make it a 2.0 issue
James: anyone disagree with making it 2.0?
James C: I think there's some value to what Curtis said, "why is the last sentence..." What if the actual solution here is just put it as the first sentence after the description now. That seems fairly actionable for 1.3, it would be a separate one in 2
Matt: that's editorial, so we could just do it
James: not actually editorial
Car: it's in a green box, maybe we should put it in a red box ;)
Matt: oh you color impaired people
James: might be the first ableist comment I've heard from Matt
Scott: if only we had aria-something="abstract"
<msumner> +100 to `aria-mood`
James: it's in the minutes now, it's official
*scribe note: INCEPTION
James: anyone want to take that on, it sounds relatively easy. It may even be editorial, since we may already have something in the normative statement that says it
Car: I can do it, do we have an issue for that?
James: let's just open a new one
Car: actually yeah, it's a great first issue. Anyone looking for a first issue:
Jory: I can take it
Meaty topic for next week
James: I propose since we didn't get through much 1.3 triage, we should continue for next week
James: or should we finish off the required and owned discussion b/c we didn't finish that, and we may even have some new things to do based on work
James: actually probably better to wait on the required/owned discussion until we have the two first parts, so let's do some 1.3 triage
1.3 triage
James: starting at #1101, it's the first one without an assignment, aside from good first issue
<jamesn> https://
James: make support for aria-disabled being conditional on the row being in grid or treegrid
Matt: actually a good first issue for someone
Matt: we already have language that does very similar things
James: what language is it in? So someone taking a first issue can reference it
Matt: something in grid, maybe selection
Sarah: the wording is under the row role
https://
James: going to comment in that with that spelling. I'll mark it with good first issue.
James: next, deprecating or special live region roles, we're going to move it to 1.4 because we're not doing anything to live regions in 1.3
James: 1106, PR automation, assigned to Harris -- you made some progress, right?
James: so 1106, we'll get that done?
Harris: if everyone's cool with that github action
James: Joanie brought up some interesting drawbacks, it's going to break any cherry picking we're doing currently, so we'll need to cherry pick everything before we do this
Joanie: but that's just to get the first public working draft of 1.3 out, right?
James: we have a whole bunch of stuff that's in main but not stable, so if we want to merge those into stable, that'd be a problem
Joanie: but are those things we want to include in the first working draft
James: there may well be things that we can't. Whenever we do it, it'll be painful, so we just need to do it at the least painful time
Joanie: that's probably just after getting the first public working draft out
Harris: someone just ping me when we want to add the github action
James: next, aria attributes has many integer attrs with string types. This is assigned to James, you still want to get it into 1.3?
James C: I do
James: next #1117
Joanie: if memory serves there's only one thing left, maybe we should redo the summary
Matt: why were they not all done at the same time?
James: we did the things we got full agreement on
Matt: ah, I remember the contention around listitem
Joanie: we've seen some focusable rowgroups in the wild, and the screen reader should say something about the nature of the group
Sarah: I've also run into visibly named rowgroups
James: so do we close the remaining ones, move it to a later thing, or do it in 1.3?
Matt: I'm a super strong advocate for the listitem and time one, but don't know about term and rowgroup. Maybe we should drop rowgroup
Matt: if you remove rowgroup
James: and listitem, because it's contentious, because there are use cases for an accessible name on the list item when the contents includes all sorts of other stuff
Matt: I think we talked about those being author errors, because it causes all sorts of AT issues when you duplicate content in a name. There is no precedence for listitem being a container in the way that group, article, region are all containers. So I personally don't think listitem should be that contentious, it was just a matter of clarifying matters to remove the contention
James: OK, let's separate these out into separate issues, and that way we can tackle them one at a time. Time can be done, and the other two can be punted.
James: I'll create those after the meeting
Action: jamesn, split #1117 into three issues for each role
James: I'm going to make Time 1.3, and the others 1.4 or later. And I'll close this one when that's done
James: 1119, consider creating a fieldset maxlength property
Joanie: I think it's worth doing, but not 1.3
James: 1.4, done
James: Add normative text about menuitem, treeitem about child elements. This sounds like what we were talking about
Matt: agree, this sounds like it should be part of that owns project
James: OK, so this stays 1.3. It does require someone to take it on, though
Matt: so the question is will you do this issue specifically, or --
James: yeah, this is more generic. I'm tempted to close, but I'll assign it to myself and do that when I look at the other issue
James: next, 1056
James: unclear purpose of aria-valuemin and aria-valuemax when aria-valuetext is defined
Matt: yeah, that's for sure
James: the ARIA spec could be clearer, yup
James: the first sentence, the spec could be clearer, that's probably relevant for all of it
Matt: it's also unclear what we want the AT behavior to be
James: 100% agree, it really is unclear
James: is this 1.3 or 1.4
James C: I don't have an opinion on the milestone, but I think there's value in leaving valuemin, valuemax, and valuenow. As an example, if it is agree, disagree, no pref, it would effectively be 0, 0.5, 1. So if a screen reader wanted to list the choices -- taking it away isn't an option
James C: if we want to clarify the prose, that's good
James: right now, the problem is valuemin, valuemax, value do nothing to benefit the user, so why should they do that
Matt: we want to get to this in ARIA-AT, and we don't have enough test cases yet. It's not clear what we want screen readers to do
Matt: I think there'll be a lot of questions around this soon
James: a lot of outstanding Qs, so we don't have enought info to do this in 1.3, should be moved to 1.4
Matt: yeah, I don't think the milestone matters much
James: OK, it is the hour, thanks all