<scribe> scribe: melanierichards

New Issue Triage

<jamesn> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-01-24+

jamesn: putting 1.2 milestone on issue #893

bryan: think we should involve Matt, who authored it

jamesn: assigning to both you and Matt

F2F Updates

<jamesn> April 31-May 2, San Francisco, CA hosted by Level Access

jamesn: F2F April 31st-May 2nd in San Francisco, hosted by LevelAccess
... target work is role parity

<jamesn> Target work Role Parity

jamesn: probably other things as well, since we have 3 days
... more details in due course, but people can plan on those dates

bryan: transportation is really easy for those coming in from different parts of the bay area, I can add details later

HarrisSchneiderman: what's the address?

jamesn: right in downtown

<jamesn> 114 Sansome

Issue Assignments - looking for owners

jamesn: looking for owners of role parity issues

<jamesn> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Arole-parity+

jongund: I can take fieldset

jamesn: please assign yourselves to some if you'd like to take some issues

joanie: I'm interested in sub and sup, so I'll take that one

jamesn: we have a lot of issues that are just targeted to milestone 1.2, we'll need to start cutting them out, or we're going to need to make progress on them very soon

<jamesn> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+milestone%3A%22ARIA+1.2%22+

jamesn: 89 open issues, which is too many if we don't start making progress

Issue 867: add draft specification for role label

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

<jamesn> https://www.w3.org/2019/01/24-aria-minutes.html#item04

<pkra> I can take cite

jamesn: last week we talked about whether it should participate in the actual label calculation, and whether there is a conflict with aria-label and aria-labelledby

mck: there are situations today where you can legally put labelledby on something, and also wrap it in a <label> tag...what does name calculation do now in that case?

bryan: if you have a regular form field, and you have a standard label element around that, then technically the entire content becomes the implicit label. there is no equivalent in ARIA

mck: if you have an HTML radio input, is labelledby permitted on that input? is that allowed?

(people say yes)

mck: let's say that something is in a label element, and points to a span with labelledby, what happens?
... is new language required in order to prevent these cases?

bryan: aria-labelledby would take precedence and ignore the rest.

jamesn: this seems more related to acc name calculation and not the new role

mck: is it correct that <label> wrapped around something with role radio, that does nothing?

bryan: yes

mck: we wouldn't have to reinvent anything for name calculation with label?

jamesn: acc name would have to be updated to allow role="label" to participate in calculation similarly to native label
... we have to ask ourselves if this is useful to add. What does having label here potentially buy us, that you can't do with aria-labelledby
... we can solve this without adding a new role

byran: role parity, beyond that I don't see the real reason we need it

jamesn: we can do role parity without adding a new role
... benefit of the role is if you have a component that acts as a label, wihout knowing what it is labeling. You could put a child element inside it and the child doesn't have to know anything about the label

stefan: label elements in the wild are punished by validators
... "hey you have a label but no association"
... validator could check for this in the label role scenario

jamesn: that may be a bug in the validator

<Stefan> https://www.w3.org/TR/html-aam-1.0/

stefan: for the HTML-AAM, I looked how label is mapped to the various APIs, it's kind of wild what's going on here
... we'll probably have the same mapping problem here
... is this an opportunity to improve the platform mappings?

mck: nesting in labels not in acc name, that's in HTML
... I'm trying to imagine mapping a grid in a label element, that sounds really weird. We'll have to give that thought: what can you actually wrap?
... in the past we haven't created a dependency b/t ARIA and HTML, not sure we want to but I think we would have to

stefan: it makes sense that we distinguish in a chunk of information what is the label and what is the value. Even if it's plain text [not input elements]

mck: you're thinking of labeling things that are not inputs?

stefan: yeah

mck: so like Name: Stefan, Age: ...

jamesn: we have a lot where there's readonly pre-populated data, you don't want to use readonly inputs, you just want plain text. very common pattern
... there's no...great solution because you don't want to put a tabstop on it, but if you don't put a tabstop on it, a SR user is not going to know it's there

stefan: we have large regions in our app like this, debating how to address this

mck: this idea of labelling things that is non-interactive is interesting. for those who know their accessibility APIs, is there a concept for that?
... this static text is a label for this other static text

joanie: this is done in some GTK dialogs
... in native UI for Linux
... and these are focusable
... the value is focusable, not the label

jamesn: if you want something to be readable, you essentially have to make it focusable

mck: in some native things, yes
... there's a part of me that really hestitates with, in the name of role parity, creating a role and then allowing that to participate in the name of other text

bryan: we had the same problem with aria-haspopup, back in the day everything had a popup, and it was really annoying
... I guarantee people will do something stupid with that (label around paragraph etc)

mck: high probability of wanting to ignore this
... you can already label a focusable paragraph today, I'm a proponent of limiting things like that

<HarrisSchneiderman> +1

jamesn: why don't we have label role have parity with HTML label element, and only allow it on things that would be allowed to labeled by the label element
... HTML element does allow label element to label the output element

mck: not sure what output is, really

jamesn: static text essentially

(question in the room of whether output creates a tab stop)

<HarrisSchneiderman> re: label elements in the wild are punished by validators - I just checked axe-core and it does not raise an issue for a label element without a "for"

aaronlev: I think it has a default politeness level

bryan: I would recommend extending "what the label role can label" just a bit to the simple widget rules, which are single focusable, like button or slider

joanie: what about a tree

<Stefan> https://htmlreference.io/element/output/

jamesn: we can have open questions, I prefer to keep it just the obvious ones to start with, and add as need be
... Jon, do you have guidance on how to do this?

<pkra> Sorry, I have to drop off early.

jongund: so in the description do we want to point to HTML5, or list them?

jamesn: list them in the prose for now

mck: this is like a required own element almost, right?

jamesn: I don't think so, it's a potential owned element
... the thing it labels is not its direct children necessarily either. can have intermediate elements

carmacleod: name from, we have that table row in every role

jamesn: ooh, interesting

mck: it would be another form of name from author

jamesn: can anything with name from author be supported by an element with label role?

mck: no, because grid allows name from author

james: some things, it would make no sense to wrap it in the label. breaking structure

jamesn: not sure I know the issue with wrapping grid in label

bryan: we could be clear about, it names the outermost widget
... it would work for trees as well, if we did it that way

mck: what does it do, bryan, if you have table element with role grid, and you wrap it in a label element, and it has a caption, and there's inputs inside the table

jamesn: I think we need to limit it to simple widgets that cannot have child widgets

jongund: agree, I think start simple and you can make it more complicated later if need be

jamesn: do you know how to progress?

jongund: yes, just add that it can be the label for the following role, and list out the roles that are lable-able by HTML

jamesn: doing it in prose is OK, we can look at doing it in the table later

mck: still strikes me as kind of odd, that if it's defined as labeling a supported element that it wraps...why couldn't supported roles be used to define which roles support it?

melanierichards: that row is available on the state and property definition tables only

mck: ah right, not available on the role tables

Range should subclass structure rather than widget

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

<joanie> https://github.com/w3c/aria/pull/894/commits/3ff5955dba66e0390292010a25596dd5e2544841

joanie: those of you who were here last week, I had a proposal for the meter role, and we had some changes and I made those. We were blocked on the fact that meter is not a widget, but inherits from range, which is a widget
... we talked about me changing subclass to structure, so I did that
... changed parent class of range, so it's now structure instead of widget
... other roles would need to have multiple inheritance. since they'd need to inherit both from range (no longer a widget) and from widget
... check out the diff I linked to, for what I verbally described

<joanie> https://pr-preview.s3.amazonaws.com/w3c/aria/894/60a9063...3ff5955.html

joanie: I think it's hard to look at this in real time, the link I just put in, you can see all the changes in the physical spec text
... only 12 changes total, there is nothing unexpected here. So I think this is side-effect free

mck: wow!
... this all sounds good to me, sounds like it worked out perfectly

joanie: permission to merge?

jamesn: any objections to merging?

mck: we have other parts of the process to help us catch anything we didnt now?

joanie: can't programmatically write tests for this. looking at characteristics table, nothing has actually changed
... looking at Gecko, Chromium, Webkit, taxonomy doesn't matter
... I will add a change log, because it's something we want people to note
... something will go in authoring practices for it?
... last item is meter

Add ‘meter’ role

<joanie> https://github.com/w3c/aria/pull/888

joanie: responded to splitting something into two sentences, and there's a note about we don't have these HTML-esque properties yet. Initially I had "authors should use aria-label to add this information", you all said rip it out, I ripped it out

mck: I had a question on the wording for range, in the last agenda topic, would it be better to say an element instead of a structure?

joanie: we're not super consistent, usually use whatever the superclass is

mck: with multiple inheritance...not sure it seems right to call it a structure

jamesn: where?

joanie: in definition of a range

mck: I think it would be better to say "element"

joanie: happy to make that change in the prose
... checking consensus, are we cool with that?

(general yeses)

joanie: what are we doing with meter, merge or wait another week?

mck: do we have to wait a whole week if people review outside of meeting time?

jamesn: we will merge it Friday at 5pm if there are no more comments in the PR

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/joanmarie/joanie/
Succeeded: s/[missed]/sub and sup/
Succeeded: s/I'll take some/I'll take that one/
Succeeded: s/know/now/
Present: Joanmarie_Diggs pkra jamesn melanierichards MarkMcCarthy janina carmacleod Stefan HarrisSchneiderman jongund BryanGaraventa MattKing
Found Scribe: melanierichards
Inferring ScribeNick: melanierichards
Found Date: 31 Jan 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)