Accessible Rich Internet Applications Working Group Teleconference -- 28 Feb 2019

<pkra> present_

<jamesn> https://github.com/w3c/aria/issues/910

New issue triage

<pkra> :)

<jamesn> https://github.com/w3c/aria/issues/909

<scribe> scribe: MarkMcCarthy

Future Meetings

jamesn: csun is coming up, we'll meet next week but not week after next
... after that, back to normal meetings. not planning a week off after csun

F2F Update

jamesn: confirming our f2f meeting page, link...?

<jongund> https://www.w3.org/WAI/ARIA/wiki/Meetings/F2F_Spring_2019

jamesn: it's April 30-May 2, hosted by LevelAccess
... SF hotels can be pricey, look outside the city. if it's near BART it'll be easy to get to levelaccess
... SF hotels can book up depending on other events, book sooner

New Issue Triage

Create address role

jemma: what's the aim for f2f?

jamesn: hopefully to get through as much of role parity as possible
... and maybe some other things!

jemma: will we have an f2f at TPAC also?

jamesn: we'll try but it's also important to meet with other groups
... on to address role, let me get a link...

<jamesn> zakimhttps://github.com/w3c/aria/issues/872

https://github.com/w3c/aria/issues/872

jamesn: we added this as we thought we needed it, HTML AAM was exposing something different - wasn't just a group
... peter did some investigating, turns out it should be exposed as a group
... so we might not need a specific role for address, it's just generic

<pkra> It was Joanie, not me who got them to chime in.

jamesn: does this sound like the right approach?

mck: what was the actual conclusion?

joanie: to treat it like a div and theyve already changed html aam

mck: so it's not mapped to role: group? good
... nobody is thinking that there's meaningful enough semantics with address role to bother with disambiguation?

jamesn: yeah

mck: taking this position is a good thing, +1

jamesn: ok, so my action is to close this specific issue and move address from a specific role to generic role section of wiki

mck: question on html side: what's the purpose? we have clear accessibility purporse, but are we missing something? possible pushback outside of aria?

<pkra> https://www.w3.org/TR/html52/grouping-content.html#the-address-element

mck: so a semantic reason for using it might be SEO?

jamesn: yeah
... this isn't exposed differently or visually different, unless there are styles applied

mck: so like a nice CSS target, okay

<jemma> 'If developers wish to provide more granular and specific semantics for the address element, use of any of the various semantic web metadata schemas is suggested."

pkra: the 5.2 spec points out devs should use microdata/schematic markup when they want to use it. for the time being it doesn't have a specific "point"

Issue 875 need role for fieldeset/legend

<jamesn> https://github.com/w3c/aria/pull/911

jamesn: so yes, we need to add something

mck: this is a lot like label role in that it removes the need for aria-labelledby and would affect name calc for groups if it's present, right?

jongund: yes

jamesn: when we were thinking about this before, we said we would expand the caption role...

mck: did we add a caption role?

joanie: it covers HTML caption and figcaption

<jamesn> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity#specific-role

Bryan: from a grouping perspective, it'd implicitly reference the caption

jamesn: is there any reason we can't use caption for legend as well?

Bryan: can't think of one

mck: looking at current editors draft...

<jamesn> caption

<jamesn> On-screen descriptive text for a figure or table in the page.

<jamesn> Authors SHOULD reference the element with role caption by setting aria-describedby on the figure or table.

joanie: we need a nice way to connect the caption to the element it's describing, this will cause an accessible relationship to be formed

mck: i thought that was implicit?

joanie: i've seen captions that are longer than what you want for an accname

mck: if the caption is sometimes providing the name (or description)... well this is a little off topic
... real issue is can we do this for group? if purpose is to provide a name, we have to revisit -describedby

Stefan: currently, readers like JAWS seeing a form, these things are treated like regions. if we attempt something like this (groups), we may lose that ability to navigate by regions.

joanie: Jon is working on a label role. while a caption is a longer thing, the text in a figcaption is shorter, and this is closer to what Stefan was saying.
... i'm wondering if legend could add to label

jamesn: that makes sense, when you look at legend mapping, it maps to label in APIs. so having the legend relate to the fieldset makes a lot of sense

jongund: accname calc would be different

mck: captions go inside and labels go outside what they label

jongund: right
... there's also certain behaviors expected

Bryan: behaviorally, if legend is the description ... that information is tacked on to something. it's not the way you typically think of a name

<Devarshi> Isn't Legend the 'group' label for the fieldset?

jamesn: bringing this back, Jon currently has a legend role being defined. we have 3 potential options
... a legend role, a label, or a caption
... is that a fair summary?

mck: if we reuse caption, do we need the relationship?

jamesn: yes

mck: I thought the point was that we didn't need to explicitly define?

jamesn: so if you had caption... you need to have a relationship.

mck: a caption labels its closest ancestor... right?

jamesn: if we're doing it with aria, does it have to be a descendent relationship?

mck: well if we're talking about role parity... this might be confusing for authors

Bryan: aria-labelledby already works like that, Jon is saying the legend would be recognized by the group it's in
... but what if they put a group with a mixture of elements like radios etc? what gets the label?

mck: so we'd have to make it clear to use the same approach as in HTML
... it's possible to create conflicts.
... or at least might be redundant

jamesn: why are we trying to mimic the HTML structure? isn't the point to allow role parity w/o enforcing the same structure?

jongund: a lot of times, people are fixing stuff. most stuff out there is made out of divs and spans

mck: the driver of HTML parity has been web components and virtual dom nodes etc.

jamesn: so... why would we create something where a legend has to be a child of a group? rather than specifying what the relationship is?

mck: the legend role isn't revealed from an a11y standpoint - it's a label. if you're pointing at it with -labelledby, then why make it a legend?

jamesn: right? So why not make it a label

mck: or any role?

jongund: the main advantage of my proposal is an auth technique that doesn't require labels

<jamesn> https://www.w3.org/TR/html-aam-1.0/#details-id-84

jongund: if aria is bigger than just html, this provides a group label with visible text in an easy way
... it simulates the features of an HTML5 legend element
... so if role=legend is on something and it's not descendent of a group, and not ref'd, it does nothing

Bryan: i understand the value from parity perspective, but it's the same from an accname perspective

mck: conceptually, the algorithm is similar. so if you have a fieldset, its browsers are already calculating it's accname from the legend?
... what jamesn was proposing was spec'ing out more flavors

Bryan: but we don't have a legend role

jamesn: which is what the PR is attempting to do
... straw poll: 3 options
... legend role, expand caption role, or use label role

<mck> +1 for legend role

jamesn: +1 for legend role?

<jongund> +1

<jamesn> +1

<HarrisSchneiderman> +1

<melanierichards> +1

<jemma> +1

<mck> +1 for bryan on legend role too

<Stefan> +1

<pkra> +1

<Devarshi> +1

jamesn: do i need to do the others? no i don't think so
... any other +1's?

joanie: 0 for all
... i need to do some more thinking

<Stefan> +1 for label as alternative

jamesn: joanie, can you look at the PR and add some comments then? all else, put comments online on PR

Need role(s) for semantic emphasis (parity for strong and em elements)

<jamesn> https://github.com/w3c/aria/issues/905

joanie: i've decided to take on strong and em, assuming we need
... HTML spec says the level of stress is given by ancestor em or strong elements. like, what???

<pkra> I feel properly represented by that.

joanie: so I put in 3 questions, in the issue.
... given time and nature of questions, lets not discuss now, but if folks could look at the issue and think about it, that'd be great
... and hopefully come to consensus. I have no proposal

The ARIA 1.1 Combobox design pattern endorses unlabelled form fields as normative spec.

<jamesn> https://github.com/w3c/aria/issues/893

jamesn: this is assigned to mck and Bryan
... carmacleod added a comment/suggestion in the issue

carmacleod: I was hoping joanie might have some ideas...

joanie: is deferring to Bryan LOL

jamesn: so my question is, the textbox child of a combobox is still exposed to AT?

mck: yeah. i've given this lots of thought. there's a part of me that wants to do the opposite of what carmacleod suggested
... even when we were writing this, we had some discussions and (verbally) agreed to kick the can. perhaps due to accname at the time
... there's also the issue that, with this pattern, it's an expectation that the popup is revealed to AT, and we want the popup item to be labelled. author could have option to give that a different label
... combobox could take its label from the child, to be more backwards compatible and author friendly

carmacleod: it announces a textbox, but user might not know about the combobox

mck: right, which is because of lack of support for 1.1

Bryan: the conflict for mapping it comes from it being a widget. there are multiple places where a label might come from; implicit mapping is really hard to predict

mck: we have the same problem w/ spinbutton
... we should solve these problems the same way

jamesn: mck, Bryan, carmacleod, can you get together and figure out a way forward?

mck: what's the urgency? maybe a side agendum for may 16 meeting

CurtBellew: what are implications for multiselect etc? I'm curious

jamesn: let's put this on agenda for f2f
... i'd like folks to to leave comments on 876, cite role issue

mck: a suggestion: if there's a top 2 or 3 hot topics, after the meeting is it possible to send an email with top action items?

jamesn: we can try it!

mck: things are said and land in minutes, but unless everyone was paying very well attention, it's hard to keep track

jamesn: yeah, we can try it. but it's essentially things in agenda we didn't get to

carmacleod: please also look at em/strong issue

<pkra> gotta go. bye!

<jemma> I added my comment to 'em' one

mck: just something to help focus attention

- DRAFT -

Accessible Rich Internet Applications Working Group Teleconference

28 Feb 2019

Attendees

Contents