Meeting minutes
jamesn: welcomes josh black and has everyone introduce themselves
New Issue Triage
https://
jamesn: I'm not sure I understand, I understand why in css there is a press before release, but do we care in aria?
scotto: I think they are looking for some kind of active state....
jamesn: do we care about an active state vs pressed state?
jcraig: maybe something act on press down and some on press up... maybe there is an option for cancellation when the action is on press down. this might be a web application question lets clarify from author?
jcraig: I'll ask
chlane: I think at vmware, they want an active state, because they do something visual.... there is a concern about whether this is not accessible?
jamesn: the question is would that actually be useful to expose that information to screen reader users? We need to know that
jamesn: we will come back to it after clarification
https://
siri: I have an action on this
New PR Triage
https://
lots of editorial PRs from scott
scotto: most are small, need reviews, intert attribute should be straightforward but i have an open question
scotto: if anyone has questions please reach out
jamesn: gets reviewers for all of scott's editorial PRs
https://
jamesn: can you get james teh to review the intert PR?
Deep Dive planning
jamesn: when will be ready for popups?
scotto: we will have to punt until we can arrange a time with aaron
jamesn: nothing scheduled for next week and the week after, currently.
ARIA interaction with MathML
jamesn: neil is not here, and he is a member of this group, and we were hoping to have this discussion with him
jamesn: but there are an explicit question about whether we can / would like to be involved
jamesn: they are asking about a mathml "intent" attribute, should there be a similar aria one?
jamesn: (continues to go over the options in the issue)
jamesn: I don't care between a2 and a3, until they work out how to use MathML, and know how what they do maps to ARIA, until they have MathML mappings to accessibility api with whatever they are doing in intent, then we can potential do an parallel aria
jcraig: it seems like there is a semantic difference.... maybe because the pronounciation is not as intended... if it unambiguous but pronounced the right way. but if it is ambiguous in Mathml, then this is something specific to mathml and not something specific to aria
jcraig: the ways the could deal with: it if it is unambigious, then we (AT+browser venders) need to fix bugs
jcraig: if it is ambigious.... (didn't catch)
jamesn: sounds like the aria group needs no further involvement at this point
jamesn: otherwise, a2 or a3 we can't weigh in on, if they want to use aria-label, that is fine.
jcraig: it sounds like they are describing browser bugs
jcraig: and that they are trying to work around them
jamesn: are we interested in option 4?
jamesn: I'm not sure there is anything useful for us to contribute until mathml figures out where all the gaps are
jcraig: I agree
jamesn: I'll reply
jamesn: anyone disagree?
scotto: I agree
<MarkMcCarthy> +1
jamesn: I'm not sure we have time given all the work we have, but if anyone is interested, they can join the mathml group
Consider adding a 'decorative image' role
scotto: this spins out of the long convo we have been having about firefox treating image with alt sent to the empty string but with the title attribute set. james teh says we shouldn't drop accessibility information if it is available. I have more proposals about image name and when images is an image, this is one proposal
scotto: we have a boolean, image is either decorative or performative
scotto: what about a middle option.... people with low vision might be unsure of a decorative image
scotto: there is a lot of images that are garbage and that people don't want access to
scotto: but who are we to decide? user agents could provide a setting to access or not access. the images could be named
scotto: I don't like the idea that they are informative or decorative and nothing in between
cyns: how is this different from role presentation?
scotto: that makes the graphic not a graphic anymore
jamesn: I agree that there is an area in the middle. one thing I come up with in apps all the time is an avatar, you don't want it voiced all the time, but you do want to know it is there and that you can reference it
jamesn: maybe the content needs an importance level?
scott: I was working with a banking client, and we had to talk about whether their images were informative or decorative, and the designed got very made that the child holding a balloon was not informative on a "how to sign up for an account" page
jamesn: well, on a marketing page, the images are there to evoke something -- maybe they can just be voiced once, and not in the future?
scotto: is this something that is nice to know?
Matt_King: I think you both said a lot of things that are important, I think there is a lot of need, this is a bold proposal, wcag might need to revivist what they say about this. one of my own use cases is when I am trying to understand what people are doing with a design. knowing what images are there, and the fact that there are even images at all? there was a lot of argument about which images were informative.
Matt_King: I like the idea of verbosity settings that can be set on a per page basis
Matt_King: it seems like there are three decisions that someone could make: informative, decorative but with meaning, graphics for spacing and layout (hopefully does not exist any more???) but probably some cases where there is zero value in the image
jamesn: is this something we should do, or should WAI adapt folks pick it up?
jamesn: this is about metadata. this might be bigger than just images. there are other things that sometimes you want to know about but not at all times
Matt_King: I think something to serve a very specific purpose, image verbosity, is potentially easily resolvable, and something we can do
Matt_King: when we find differences in what browsers are doing... we might be able to do something achievable to fix it
cyns: I'm coming around on this idea. another example: I worked on a recruiting site, every page had huge picture that was the main content (happy employees)
jamesn: I want to clarify -- would we envision this new role being available from html with no idea? for example, not alt but a title?
scotto: yes, the goal is that that would be the same thing
scotto: the other solution is that instead of becoming presentational, it becomes generic -- which exposes the information but does not expose that it is a graphic. not sure this is a good idea.
scotto: I shopped around the issues' idea and got some positive feedback
cyns: we could also propose an html attribute...? I think it is easier now than it used to be
jamesn: is this a openui project?
cyns: I think they do more like complex controls, but we could ask
siri: in the no alt, but title, title becomes the desc? if role=decorative....
jamesn: I think we aren't sure, we are not yet discussing actual implementations
Matt_King: if the role is decorative, you can put aria-label, like any other image?
<Zakim> cyns, you wanted to say alt="" title="string" is too obscure. Would be better to add an html or aria attribute describing this type of medium-importance image
CurtBellew: in that case, if we had an alt attribute with text, and role=decorative, and the screen reader decides when and where to read it?
scotto: image with alt="" (means presentational image), but then if you add title, then you are giving the browser mixed messages
<MarkMcCarthy> Matt_King: are you saying role=presentation title=somestring and alt="" would be the same as role=image title=somestring? (I think I got that)
<MarkMcCarthy> scotto: essentially, yes (I think, Scott?)
<Zakim> cyns, you wanted to say that I don't love "decorative" would like a word that describes this medium-importance type of image
<siri> semi decorative lol
<jamesn> "evocative" ;)
<MarkMcCarthy> cyns: i'm not a fan of the word "decorative", it's been used to mean "unimportant" for so long
scotto: I agree. I'm open to other names
chlane: the great thing about this, anecdotally, I've been hiding content...
chlane: that I think people might want to see
chlane: I think "decorative" is a good word though
myasonik: I like the importance idea -- because I can easily imagine other scenarios
<chlane> fluff setting
dakahn: I like the idea of the user coming to the content with their own context, people might be just wanting to get something done on a platform they know, in other scenarios maybe they have time and want to see/know about all the content
dakahn: I like the idea of better alt tags, maybe this could encourage? if you know that some people choose to experience it with the content you have otherwise written
<MarkMcCarthy> General +1 to the entire convo - don't want to take time to say so :)
jamesn: sounds like people have general agreement! cool
CurtBellew: there is nothing about a contextual image. helps to establish context
jamesn: consider this general approval to keep going
scotto: I've given myself more work! I'll reach out to AT people
Does aria-hidden obey DOM or AX tree ancestors?
<MarkMcCarthy> jamesn: we talked about this before right?
<MarkMcCarthy> spectranaut: yep - discussion in the issue
Matt_King: what does "aria-hidden" mean? james teh thinks the node is ignored/does not effect the accessibility tree?
Matt_King: what do AUTHORS think? this is the important question. aria-hidden might be expected to behave like "display: none"
cyns: I'm confused, it sounds like aria-hidden.... it does hide dom children? I don't know what authors expect it to do with "owns" or "control" based children
cyns: I woudn't expect that to work
Matt_King: definitely not controls, owns is defined as reorganizing inheritance specifically for the accessibility tree
cyns: I think we need to look at the performance impacts, and how confused authors are about it
Matt_King: we need to make sure the spec is consistent and clear. we could write that an owned element does not inherit hidden, but it does inherit selected and checked. we need to look at how inheritance works. I think we should be consistent in the ways we treat attributes
jamesn: probably needs further discussion, lets take up next meeting