Meeting minutes
<jamesn> title: ARIA deep dive
<scotto_> https://
bryan: implicit generic role elements.. previously only div and span, but there are a bunch of html elements that could use this
bryan: the goal is to identify which elements those are
bryan: important for how it maps in the accname
jamesn: we have agreement on 10 from the issue, and questions on the remaining seven
scotto_: when we were previously working on role parity, the text level semantics were thought of as being possible generics. others such as hgroup are now mapped to generic. there are still other elements that have semantic importance, such as audio/video/embed/iframe, where we didn't call out that they get a role, they don't have a role defined, but they still have accessibility mapping. when I was trying to map the elements to
generic in this issue... [scott gets philosophical about the meaning of words]
scotto_: how pedantic do we want to be about the code role? what about var, keyboard... if exposed... might be only exposed by change of voice. the b, i and u are generally thought of as holdovers from html past, have no semantic meaning, but in html they have a semantic meaning
scotto_: why aren't they all emphasis role?
scotto_: they do represent something
scotto_: voiceover can navigate by styling of these elements?
scotto_: do we need a role for things? such as audio/video? is everything a group?
jcraig: the primary way a mac voiceover user would jump between these kinds of elements and determine what kind of visual styling properties they have -- 1 you can jump to the next differently styled element, 2 you can change the verbosity settings so that style changes are announced (from bold to normal, etc), sometimes footnotes or titles are emphasized 3 they can, where ever the cursor is, ask for the style properties, which are
very specific
jcraig: as such, there is not significant semantic difference in the accessibility tree
jcraig: that was my point for a related issue, these are all stylistic hooks. as they are implemented in the style sheet. in the platform apis some things get mapped differently
bryan: any specific elements that are namable? that you would like to expose and accessible name? not these style ones, but maybe others, like video?
jcraig: maybe not namable... but dd and dt and figcaption have some semantics. var could map to code. pre might map to code.
jcraig: the stylistic ones, there is no reason to have a special role for them
scotto_: back to the naming question, I've come across a few instance where there could have been an address element. for example, home vs office address. but there is no visual heading to differentiate between the two, just an icon
jamesn: but the icon could have an accessible name
scotto_: but there is no direct programmatic association between the two
jcraig: could be a background image style and there is no way to make it a label
jamesn: but you could add a group or something to name it
jamesn: you don't want <address role="group">, they can add aria-label somewhere else
jamesn: we don't allow naming of this kind of stuff, there is a work around, we shouldn't change for a corner case
scotto_: at one point address was mapped to contentinfo
jamesn: oh I see so maybe this should be considered
jamesn: I was going to suggest, why would we not map <b> to role strong?
jamesn: if the default rendering is the same, why don't we map them the same
jcraig: why do we have a role of strong?
jamesn: role parity
jcraig: but strong is generic as well
jamesn: why did we introduce it in 1.3?
jcraig: I was opposed to it. I want role parity, EXCEPT for stylistic stuff
jcraig: in mac, they are all generic
aaronl: I can't easily check what chrome does rn
jamesn: there is a subrole, "strong style group"
aaronl: generic role for stylistic elements
aaronl: in chrome, in the AXTree
jcraig: I've never see ax strong style group
jcraig: I doubt that subrole is being used by AT like VO
jcraig: but we now have a difference between things that are styled as bold and things that are <strong>, without any functional reason
bryan: we have role parity, what I would like from this discussion, is what is mapped to generic but have a sensible role mapping, and which things should be mapped to generic
scotto_: what about audio, where there are platform controls and control types, but no aria roles
scotto_: for some of the things in this issue.... like abbr... is that really a generic??
if you have three uppercase letters, voice as A-D-D not "add"
bryan: does anyone disagree with the 10 more obvious ones
jamesn: maybe we should go through 1 by 1
jamesn: first, is "area" with no href
jamesn: map to generic
jcraig: generic implies that something should be in the tree... but without href maybe it should be not mapped, not in the tree?
jamesn: but if it has no href, but as an alt, wouldn't it be mapped?
jcraig: in theory sure, but I've never seen it before, but I guess it should be generic
jamesn: why not call it generic, because "who cares?"
jcraig: not reasonable for automation tests....
aaronl: you can put whatever you want in a map, including paragraphs
jcraig: the implementation difference is negligible where it is empty
jamesn: NEXT: b, any object to generic?
scotto_: b and i are suppose to have no special meeting in html
jcraig: this surprised me, because strong and emph are mapped.... maybe they should have subroles....
jamesn: we are not introducing a b role
jamesn: if we map it to strong, then that would go against what html is doing, which is trying to make these things different
scotto_: I would not expect AT to announce these roles, ever, it is just to indicate the same changes to bold
scotto_: maybe in the future, they would announce b if we map it, but not font-weight=bold
jamesn: I fear us setting ourselves up for a fight if we map b and strong the same
jamesn: we have other things to do
scotto_: per your point, james, we can map these to generic as was previously decided. if I ever feel like I want to frustrate my week, I'll look into further
jamesn: NEXT: kbd
jcraig: I don't think this should be generic
bryan: but what do we map it to?
scotto_: visual resembled like code?
jcraig: speech could know that ctrl means "control" not "c-t-r-l"
bryan: when using jaws, I can't think of a time when the name would be exposed for kbd
jcraig: well issue 1, I think it should be generic, and issue 2, whether or not it should take a name
bryan: the angle I'm coming from, if it is not generic and not mapped, then it can receive and accesible name
jcraig: we should have some non-generic elements that are not namable?
scotto_: I'll make a new issue for the acc name
jamesn: anything that we are not sure should be broken out into an issue
jamesn: NEXT: pre
jcraig: it is exposed differently, based on styles
jcraig: because these elements are pre-formatted. I think this is generic
scotto_: indenting would occur, but the font style could be changed from not mono
jcraig: but the AT already navigates by line
jcraig: you can speak the tabs
jamesn: I'm good with generic, any disagreement?
jamesn: NEXT: q
scotto_: also generic, it just adds quote on either side of the text
jcraig: I think voice over ... the quotes are used a css generated content in a before and after pseudo element
jcraig: I think firefox maps against the DOM but may have special cased pseudo elements. I don't know what chrome does, but they recently shifted to use the DOM tree, rather than the render tree
scotto_: nvda and jaws speak pseudo content
scotto_: I think inline generic
jamesn: NEXT: s
jcraig: generic
scotto_: it represent not deleted content, but content that is no longer relevant, where you have an old price. but if the old content is announced without extra information
scotto_: but maybe you can infer the lower number is the price?
jamesn: I think strike through text should be read by default because in all cases it is important to know. I can't think of a single case where it is not useful
aaronl: we asked jaws to read it by default they had turned it off for some reason
jamesn: would it help screen readers if this actually had a role.....???
aaronl: but what if there is another role on there?
jamesn: it seems like this is something screen readers should do soemthing with and what can we do to help them?
aaronl: it is a slow rolling movement... google docs is trying to get better support so they are working with jaws and nvda
jcraig: I'm not sure what the change out be we already exposed the style
jamesn: but does voice over or can voice over announce this info by default
jcraig: we normally announce by speaking at a lower pitch
jcraig: voice over could probably do by default... by mapping it to <del>
jcraig: if this was an aria change to map to del, it seems reasonable to me
jcraig: an easy change in webkit and voiceover
aaronl: what if there is another role there, who would win?
jamesn: <s role="checkbox">? what is this?
jcraig: lets raise a separate issue in aria for this ^
aaronl: I'm not worried about <s role="checkbox"> but I am <div role=menuitem style=strikethrough>
jamesn: but you would also have disabled in that case
scotto_: lets say small and u are generic
scotto_: I'll open an issue for var, saying should we map it to code
scotto_: we would want to change the definition to make them a bit more generic, rather than specific parity for one html element
scotto_: bdi and bdo, I think they are generic.....
general agreement
scotto_: cite has some additional semantics that make it more than just a piece of text, you can reference the url you are siting by an attribute. I think we need an issue for this one
scotto_: address, I think there is usefulness in mapping to group
jamesn: I'm ok with that
general agreement
scotto_: figcaption, nothing to do, we already agree
scotto_: label and legend, they have the same mapping in core-aam, similar to caption
scotto_: I'm curious if we need these at all, but its more than a 4 min convo
scotto_: I think we need to talk about audio, video, iframe
scotto_: because they should be namable
<Zakim> jcraig, you wanted to say what if role maps to "reserved:audio"
bryan: action item, do we need to talk about this in ARIA working group?
jamesn: we have this meeting notes, and many members in this group
aaronl: we need a list of the changes and a short reason for the change
scotto_: I will work on all this and make a response and make follow up issues