ARIA Face to Face Day 3 -- 02 May 2019

<joanie> scribe: joanie

Need to sanity check roles which support aria-expanded

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

mk: To summarize what I have in my pull request description:
... There are minor changes to the definition of aria-expanded
... Previously, it said to put it on element which gets expanded or collapsed or controls something which does
... Now it needs to be on a focusable element which controls or owns the thing which gets expanded or collapsed.
... Example, a treeitem which would get a child group upon expansion would have aria-expanded.
... Emphasis: aria-expanded goes on the element which does the expanding/collapsing.
... I also had to reword an author-related normative statement.
... There had been some content in there related to the benefits for different users.
... This might be practices, but it seemed unneeded in the spec.
... The rest is changing what roles aria-expanded is supported on.
... I removed it from some, but doing so caused it to be removed from other roles where it belongs, so I had to manually add it there.
... In the pull request, I put a list of all the things it got removed from

<mck> alert

<mck> alertdialog

<mck> article

<mck> banner

<mck> blockquote

<mck> caption

<mck> cell

<mck> complementary

<mck> contentinfo

<mck> definition

<mck> deletion

<mck> dialog

<mck> directory

<mck> feed

<mck> figure

<mck> form

<mck> grid

<mck> group

<mck> heading

<mck> img

<mck> insertion

<mck> label

<mck> landmark

<mck> legend

<mck> list

<mck> listitem

<mck> log

<mck> main

<mck> marquee

<mck> math

<mck> menu

<mck> menubar

<mck> navigation

<mck> note

<mck> paragraph

<mck> radiogroup

<mck> region

<mck> search

<mck> select

<mck> status

<mck> subscript

<mck> superscript

<mck> table

<mck> tabpanel

<mck> term

<mck> time

<mck> timer

<mck> toolbar

<mck> tooltip

<mck> tree

<mck> treegrid

mk: so that's the extent of the pull request. The wording part is something we should probably discuss

bg: is it on listbox?

mk: yes, it still is.
... There are three roles that really shouldn't have it, but do have it.
... columnheader, menuitemradio, menuitemcheckbox

jn: columnheader could collapse a column.

<carmacleod> Here's Birkir's email. The use case is displaying new form content when a user selects a checkbox in a form. https://lists.w3.org/Archives/Public/public-aria/2016Feb/0084.html

mk: But then the columnheader goes away and you couldn't re-expand it.

jn: I agree this is a stretch, but...

mk: I would rather remove it and wait for someone to make a case for it.

jn: I think this is a safe thing to do.
... And it clarifies exactly where it belongs, namely on the element that expands things.

mk: To change it for the three extra things, I would have to change the ontology.

jn: Please don't. Let's keep it simple.

mk: I will do this as a separate pull request (the ontology change)

jd: I think it's a potentially good idea to make the change

mr: I was pulling up all the different APIs to see what aria-expanded maps to.
... The descriptions suggest it applies to the parent

<jamesn> jd: what is the difference for someone who consumes it?

<jamesn> mr: don't think there is a functional difference

<jamesn> jd: unless core-aam has something I'm no0t aware of

<jamesn> jd: if the thing the user arrows to is the tree item - that is the thing I'd already expect to have the ewxpanded on.

<jamesn> mr: example I'm thinking of is a button that controls something else but its children arent being expanded

<jamesn> mk: if you have a button controlling a div and that div contains content then aria-expanded goes on the button that way the user when focus is on the button can hear the state change

<jamesn> mk: they know (or could) as AT user by aria-controls. When collapsed you are controlling something that is not there

<jamesn> mr: if no UX problem then not a problem but a different assumption here

<jamesn> mr: if not concerning ok

<jamesn> jd: only going to be on the interactive thing that does the expansion. ATK state expanded is in the right place

<jamesn> ... state expanded belongs there

<jamesn> ... if you think otherwise docs need fixing

<jamesn> mr: when they are 2 different objects maybe confusing

<jamesn> jd: "children"

<jamesn> bg: aria tabs aria-expanded was meant to be on the tab panel and no technology supported that

<jamesn> bg: differences between platform mappings and what you are talking about - states and properties only exposed on the thing with focus.

<jamesn> ... or aria-activedescendent

<jamesn> ... historically s&p only exposed on active element

mk: It also got even more popular with native mobile, where these disclosure patterns are needed
... Screen reader users are even more used to hearing expanded/collapsed on the button.
... What doc were you quoting Melanie?

mr: I checked pretty much all of them (UIA, ATK, MSAA, etc.)

<melanierichards> https://docs.microsoft.com/en-us/windows/desktop/api/UIAutomationCore/ne-uiautomationcore-expandcollapsestate

<melanierichards> https://developer.apple.com/documentation/appkit/nsaccessibility/1535045-accessibilityexpanded

<melanierichards> https://developer.gnome.org/atk/unstable/atk-AtkState.html

<melanierichards> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Accessibility/AT-APIs/MSAA/States

mk: I didn't actually check core-aam

jd: It doesn't change anything

<melanierichards> https://docs.microsoft.com/en-us/windows/desktop/WinAuto/object-state-constants

jd: I think the doc problem is that in native toolkits, the expansion took place on children/descendants. ARIA makes it possible to have owned elements, controlled elements, and the like that the doc writers didn't know existed.

mk: in tree grid, you are focusing rows.
... and rows can be controlling child rows.

bg: But I'm thinking static tables.

mk: In that case you'd put it on a link or button or something in the cell.

jn: Do we want to review anything more?
... Preview link?

https://pr-preview.s3.amazonaws.com/w3c/aria/pull/972.html

group: (reads silently)

jn: Do we have a definition of a grouping element?

mk: Not really, but it's anything that is grouping other stuff.

jn: But what about a single child element? Is there always a grouping element.

bg: If it were a button, it wouldn't make any sense.

cm: Nit: "controled" should be "controlled"

mk: What is tapered prompts?

group: (crickets)

mk: It's in related concepts for aria-expanded, and I left it there

<jamesn> "Tapered prompts are those that may change with each attempt. Information-requesting prompts may become more terse under the assumption that the user is becoming more familiar with the task. Help messages become more detailed perhaps, under the assumption that the user needs more help. Or, prompts can change just to make the interaction more interesting."

jd: Having searched DuckDuckGo for "'tapered prompts' smil", the first results are our specs.
... Let's remove it. Agreed?

mk: Sure.
... I'm leaving switch.

jd: huh?

mk: It's in related concepts.

group: (remove it)

jn: If no one knows what they are....

mk: changes pushed

cm: More SMIL references!

jn + jd: New issue and pull request please. Right now we're trying to fix aria-expanded

cm: Understood.

group: (More nit fixing and discussion)

jn: What about on application?

jd: I think it probably should be.

jn: Different issue?

mk: The current issue is to ensure we have aria-expanded on all the roles it belongs on, and not on the roles where it doesn't.
... I'm willing to add it.
... The definition of "undefined" is weird.

jn: It needs to be there. It can be expanded, not expanded, or not expandable at all.
... aria-expanded implies you can change its state

mk: I disagree.
... If you have a treeitem and the tree is expanded and cannot be collapsed, does that mean....

jn: You're right. It doesn't say that you can expand it necessarily.

bg: If you have a listbox with multiple items showing, it's visually expanded.
... I have had people suggest that using something like CSS to show one or a few elements means that the element in question is collapsed/expanded.
... But I don't think that makse sense in terms of using aria-expanded.

mk: Undefined, "The element does not own or control a grouping element that has an expanded or collapsed state"?
... I was trying to capture what you said, James.

jn: Don't worry about that. Let's try to keep it simple and not add words that someone might misunderstand.

jd: Do we need to test removal?

mc: We don't need to test the non-implementation.

jn: We can do this through the validator.

hs: We have a validator (axe-core) and can add a rule for this condition.

jn: Can we add it to ACT?

mc: Let's file in issue in github.

jn: Or I can just email Wilco.

mc: When we do a wide-review draft, we might wish to explicitly point this out.
... We might want a detailed changelog

jd: Are we going to land this today? If so, one of us should do the detailed changelog entry today so we don't forget.

jn: Anything more?

jd: Land it.

jn: Land it.
... Objections?

group: no.

jd: I will merge it and do a changelog.

<HarrisSchneiderman> https://github.com/w3c/aria/issues/517

<melanierichards> scribe: melanierichards

Role parity, part 3

jamesn: audio and video we don't currently have anything
... how about cite? Peter is going to do cite...
... let's try and get some of the existing PRs merged
... code

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

HarrisSchneiderman: I changed it to a section based on Carolyn's feedback

[group reads the preview]

HarrisSchneiderman: borrowed language from HTML

jamesn: second sentence is really funky ("This includes any string that a computer would recognize.")

HarrisSchneiderman: agreed

[group agrees to delete that sentence]

jamesn: should we put something in here that would be useful for AT?

joanie: yes, steal my language from the math one and sanity check it for not-math

<joanie> https://raw.githack.com/w3c/aria/math/index.html#math

jamesn: I assume aria-expanded won't exist on this one either?

HarrisSchneiderman: no

joanie: prefer spoken symbols applies to this one too
... prefer punctuation verbosity, doesn't necessarily have to be a list

HarrisSchneiderman: use a SHOULD?

joanie: yes

mck: for ATs we don't really do shoulds, we have musts or mays

joanie: I think this should be a should

mck: this is a suggestion

joanie: it's a strong suggestion, otherwise this role is useless

[joanie finds precedence in the spec]

HarrisSchneiderman: should I use "ATs" instead of "screen readers and other tools"

joanie: well this one would be about text to speech
... you can steal from my math role text
... the only real benefit of this role is to have SRs change their pronunciation

jamesn: when you go through spaces will it says "tab" or "space"?
... I was joking

joanie: there will be literal characters, so if you come across a tab screen readers will read it as tab automatically
... so we don't need a note on that

HarrisSchneiderman: the only part I don't like is the first sentence

<HarrisSchneiderman> The primary purpose of the code role is to inform assistive technologies that the content is computer code and thus may require special presentation, in particular with respect to synthesized speech.

jamesn: computer code is probably the best I can come up with

HarrisSchneiderman: yeah that seems less awkward than "code"

jamesn: if you're doing a code block you usually use <pre> as well, which gives you spacing stuff. <code> doesn't preserve spacing

HarrisSchneiderman: sometimes you use <code> inline

mck: we have a separate thing to do <pre> role parity

joanie: I think it was a generic role with a text attribute to preserve whitespace formatting
... I'm not sure we need examples

melanierichards: the first one will give users a result they don't expect because the HTML will not be rendered as code

mck: no examples because we don't want people to use it

joanie: I want to prune out more examples from the spec, we don't want authors to look at the spec for examples, we want them to look at the APG for examples

mck: we haven't addressed math in the APG and we don't plan to do so in the near future

joanie: Peter would probably be the right person to do that

[group agrees to remove examples from code role]

HarrisSchneiderman: pushed the changes

jamesn: do we need a note about the fact that at the time there's no way to imply the language the code is written in?

joanie: I need a note like that for the meter role because there's optimum etc. When we do attribute parity in 1.3 it'll make sense to do those attributes for meter. If it's not coming in 1.3...?

jamesn: it's not
... reads a note from HTML spec which says there's no way to mark language

HarrisSchneiderman: I'm in favor of removing that note

[group agrees to remove note about language]

bgaraventa1979: can you label a code element?

jamesn: hopefully not soon
... all of the newly added roles should be on the list of "Do we want these to be labeled or not?"

mck: instead of "Screen readers and other tools" we should say "screen readers and other assistive technologies"?

jamesn: eh, we can leave it. I don't see it adds anything to change it

mck: it's a normative statement...
... I'd rather have it say "assistive technologies which renders speech, such as screen readers"

jamesn: [paraphrased] I think it's good to include ANY tools that might read speech, not just ATs

joanie: I have an android notification reader that will read notifications when I have my headphones plugged in. If an ARIA notification comes up, I would want that to read hyphens
... do you think it actually hurts anything? Can you live with it

mck: I can live with it
... is there a missing period after the word "spoken"?

HarrisSchneiderman: yes
... just pushed the punctuation change

jamesn: should we merge?

[group agrees]

HarrisSchneiderman: #969

jamesn: [looks at the dl-parity PR]
... seems jon updated it with new names [reads out]

<HarrisSchneiderman> https://pr-preview.s3.amazonaws.com/w3c/aria/pull/971.html

<HarrisSchneiderman> https://github.com/w3c/aria/pull/971

jamesn: looks like this is ready to merge

[group belatedly celebrates Harris first's merged contribution]

joanie: serious question. On the generic role, we had talked about landing it independently of the text separation issue. Do we have a PR right now that we can land?

<HarrisSchneiderman> I pasted wrong link

<HarrisSchneiderman> https://github.com/w3c/aria/pull/951

jamesn: not right now, let's get through these PRs and then return to it
... let's move onto dl again

Association List

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

jamesn: is this ready to go now? Jon made updates based on yesterday's discussion, I believe

<jamesn> https://raw.githack.com/w3c/aria/issue504-description-list-roles/index.html#descriptionitem

<carmacleod> https://raw.githack.com/w3c/aria/issue504-description-list-roles/index.html#associationlist

melanierichards: one nit, in "Required owned elements", key should come before value so it matches everything else

carmacleod: looking at associationlist, second paragraph has "each" in it, can we wordsmith it so that there can be multiple key items with one or more values?

melanierichards: there's also one reference in the associationlist prose to "description list", should update that to "association list"

(sentence beginning "MUST only use an element with role")

HarrisSchneiderman: per Carolyn's nit, that second bold point is also kind of wrong, a key could have a key sibling

carmacleod: "a list of key items having one or more key values"?

[yes from a couple people]

[jamesn is making changes, requests new language pasted into IRC]

mck: "when using the association list, authors MUST:" should precede that list so it's normative

jamesn: but the first bullet has a must and the second is a should

[group thinks we should flatten to a paragraph]

<carmacleod> Change 2nd paragraph to: "...a list of one or more key items having one or more values."

jamesn: you can wrap the keys and values in a grouping container of some sort, like a div
... div will be generic of some sort

HarrisSchneiderman: reading about that first child, as a dev I would assume that you can't have anything between

mck: in gridcell, we talk about how it has to be within a rowgroup or something like that. What we're doing here we're saying what the required owned elements are. In a dl, can you have a dl with a dt and nothing else in it? Is that valid?

jamesn: possibly. It wouldn't be useful.

mck: do we need a single statement, "Authors MUST ensure that an association list contains at least one of these and one of those?"
... these other requirements can be in the other roles

<HarrisSchneiderman> https://github.com/w3c/aria/issues/748

jamesn: we do have an issue about "required owned elements", used to say it can be anywhere in the tree below it, that's not really useful. What I think we mean is that the only intermediate elements would be those that don't have any semantics

[harris pasted in that issue]

mck: there may be other places where required owned elements don't mean that though

jamesn: I think that's why we haven't resolved
... is it allowed to have a list without any items in it?

mck: it doesn't get rendered I think

joanie: Gecko does at least. I think HTML allows it

jamesn: a list could have no list items but sometimes it does

mck: ARIA could have its own reqs that go above HTML, but this is about role parity. We're doing it because of HTML

<HarrisSchneiderman> https://www.w3.org/TR/html5/grouping-content.html#the-dl-element

mck: this is a situation where someone might use it in a way that we don't think they should

HarrisSchneiderman: "zero or more"
... zero or more terms or descriptions

mck: so can we just delete all those reqs if we have them listed under required owned elements?

jamesn: [reads from HTML spec]
... you can put a script as a child of a DL
... "script-supporting elements"

mck: in our list role I don't think we put anything like this

HarrisSchneiderman: are you getting at that we can remove those bullet points?

mck: yes

<HarrisSchneiderman> +1

mck: in list we don't have reqs like this. I vote we get rid of the author reqs here, put guidance in authoring practices, tell people not to use it.

[group agrees]

[jamesn takes point to update]

joanie: doesn't required owned elements mean if there are children they must be those?

jamesn: no, it means they must be there

joanie: well then we have a problem with list

mck: this is a muddy area

joanie: we might need to tweak the definition of "required owned elements", not that we want to remove those here

HarrisSchneiderman: issue #748

mck: maybe something like "Permitted owned elements"

jamesn: there's some things that don't make any sense without children, like a menu without any menuitems

HarrisSchneiderman: well, a menu-building application

jamesn: I'm removing the author requirements
... or am I not?

mck: well it can't be a must. Is it allowed to have it be...where would we say a value is preceded by a key? It could be a should, but it's not a must

jamesn: if you have a value, do you have to have a key?

joanie: well, values have keys by definition. HTML doesn't use key/value, we came up with that
... I didn't like the language anymore yesterday because in this context you can have a value without a key

<HarrisSchneiderman> Each term-description group consists of one or more terms (represented by dt elements) possibly as children of a div element child, and one or more descriptions (represented by dd elements possibly as children of a div element child), ignoring any nodes other than dt and dd element children, and dt and dd elements that are children of div element children within a single dl element.

^ pasted from HTML spec

mck: I think you can copy that and just replace term with key, etc

jamesn: do we think we're gonna finish this one now?

mck: we need to smith it more. I don't like the normative statement now

HarrisSchneiderman: I could paste that into the PR now?

mck: I think that's a good idea
... you can put something a little messy in there and I'll clean it up

jamesn: can we take it as an editorial task to wordsmith this?

mck: I think we need people to review it again. It's not merge-ready

carmacleod: has anyone noticed that required context role is wrong for the child elements?

jamesn: oh thanks, I'll fix that

<HarrisSchneiderman> add this as link: https://www.w3.org/TR/html5/textlevel-semantics.html#the-code-element

<HarrisSchneiderman> automagically generate changelog from commit messages: https://github.com/conventional-changelog/standard-version

<HarrisSchneiderman> scribe: HarrisSchneiderman

GitHub: https://github.com/w3c/aria/issues/921

During a discussion on the a11y Slack with, the notion of required parity with HTML on checkboxes was raised. Though not often used and a bit odd, there are cases where it is beneficial to have an HTML required attribute on a checkbox and, as such, would benefit from aria-required being allowed in kind

mck: I have 1 question related to how this works...
... when you have a group of checkboxes and want at least 1 checked, if you put required on each one it sounds really weird. Is there another way to do that?

jamesn: to step back a bit...what does it mean to have a required checkbox

joanie: required by definition means the checkbox must be checked

mck: you could make a radiogroup required
... basically, it is a barrier to going forward
... if there's a submit button, and it is disabled until all required fields are "filled out"
... there isn't a strong argument I can think of that says "you must not use a checkbox in that situation"

jamesn: A checkbox means I'm saying yes or no to something (not to be confused with the radio example). Both are valid values
... "No" is an answer just as "Yes" is an answer (or true/false)

mc: An unchecked checkbox could me no, but it could also mean I haven't encounted / interacted with this element

jamesn: 1.3 we potentially could need this
... in the terms/conditions case, you can have a non-required checkbox with an error message saying "you must check this to continue"

joanie: if we could bring up a list of all required fields with AT, then it'd make sense to see that checkbox in the list because it is a prereq to successful submit

bg: can you use the actual "required" attribute on an html checkbox

jamesn: yes

<carmacleod> From: http://w3c.github.io/html/sec-forms.html#checkbox-state-typecheckbox

<carmacleod> Constraint validation: If the element is required and its checkedness is false, then the element is suffering from being missing.

<carmacleod> http://w3c.github.io/html/sec-forms.html#suffer-from-being-missing

mc: This sounds like an accommodation to HTML from ~30 years ago

mck: I do question some of our current roles that aria-required is allowed on
... like gridcell

joanie: but a gridcell can be editable, no?

bg: We changed the definition of that because editable simply means you can change the value, but that doesn't necessarily mean that the element itself is editable

mck: columnheader and rowheader are weird for aria-required

jamesn: you're not saying that this is required, you're saying that you must agree to this one thing

mck: Is html likely to change this?

jamesn: 100% no

mck: not aligning with html will persistently come along and poke us
... and sort of hurts our credible

jamesn: the group of checkboxes example is not something we need to solve because there should be some visible text stating how many selections are needed
... lets assign it to stefan

<working github contribution stuff out...?

jamesn: should we try to merge strong/em?

joanie: remember we considered not allowing it around a pre?

jamesn: does this apply to other roles as well?

em/strong 5 min

mck: to your question of other roles that would have a similar concern...
... subscript and superscript might
... I don't remember the language used there
... em says that it is 1 or more characters
... whereas strong was a "section"
... so the 1 or more characters already effects defintion
... strong gave you no such idea
... I don't think that it's sufficient as far as limiting usage
... but at least it gives some indication that it has some applicability
... the shortest answer is yes there could be a couple new roles

jamesn: then can we merge the PR and create a new issue regarding these roles and limiting their children

joanie: I'm fine with that
... maybe we should take 1 last pass at it

https://github.com/w3c/aria/pull/953

joanie: have all of these comments been addressed?

mck: were there changes outside of this PR?

joanie: the diff shows just the 2 sections
... <merging> (merge monkey)

carmecleod: should we try to capture scott/matt's comments in the issue?

jamesn: html allows certain types of focusable children
... if html doesn't allow table children, then we shouldn't allow grid (potentially...)
... what does it mean to have a strong around an input element?

mc: Some of this might be avoiding specific exceptions

jamesn: there are a TON of exceptions
... if you follow through to each of the definitions you can check what is allowed within it
... its not very simple/logical

mck: I can see if you had strong around a paragraph
... or even inside of a paragraph and theres a bunch of text and within that text theres an input
... you'd effectively be "strengthening" the text of the paragraph (which happens to include an input)

jamesn: I fear that this will be a can of worms

mck: depends on how we do this

jamesn: we should keep an open mind when investigating the cost of doing it

carmacleod: fair enough

joanie: we have no idea how AT will deal with this type of content wrapped in a strong

jamesn: the remaining roles we have are audio and video

joanie: does part 4 have the native prefixing?

jamesn: not currently because we don't have that anywhere

joanie: audio/video is quite tied to the native prefixing

mck: for role parity, theres an audio tag and video tag, so what else is there?

jamesn: we need james craig to weigh in on this subject

audio/video

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

joanie: if we had custom components, which I no next to nothing about, would they magically make it work like a native one?

<jamesn> https://github.com/w3c/aria/issues/529#issuecomment-437093886

mck: if you were going to make a video player with ARIA, you'd just do it using all of the other aria roles that you'd need (Button, region, etc..)

joanie: how do you convey to AT that a thing is a video

mck: we'd had proposals for specific attributes relating to this
... to the IOS trait "plays media" (or something like that)

joanie: I have an idea...what about a property "aria-playsmedia" (or something like that)?

jamesn: someone using this in a web component is never going to be doing anything functional

joanie: If someone follows the aria practices guide, I'd (as a screen reader) would have no idea what is going on
... James is opposed to us having role=video/audio in general
... we're preventing authors who could actually do it well from doing this
... if we call it a group, then that solves role parity stuff. If we have an attribute that tells AT this is a media thing, then that tells it that we have an audio or video player
... aria-playsmedia="audio" / aria-playsmedia="video"
... that we we're not creating roles that james craig opposes

mck: normally, with all other HTML elements that generates specific behavior we don't have the same thing in ARIA - it is up to the author to supplement
... a role=video creates a promise of some kind that this does what video elements do

HarrisSchneiderman: like a css animation sequence could be wrapped in a role=video and equipped with video player controls

joanie: if we're not going to get consensus, we can still have authors make that commitment. This should just be a group role

mck: I don't know if that is much different than having a role
... I want to understand the objections
... we're doing role parity because we were asked to do it
... If we were told "We want role parity except for specific things" then we can just punt

joanie: do authors want to make their own audio/video players

jamesn: a canvas element could be a video
... a gif could also be a video

mck: punting seems just fine here

jamesn: it'd be nice if a computed role always returned something
... so if we don't have a video role, what would it return for video?

joanie: null

jamesn: would alice's suggestion of mapping to "html:video" make sense then?

joanie: but that doesn't solve the custom element problem

jamesn: password would return something right? like textbox?
... if someone is going to create a custom password input, their not getting much out of it

mck: so it seems to me like the 1 option here is to find out what the objections are
... if the objective is just to return a computed role, then I think we should return "html:video" / "html:audio"
... maybe theres a reason they couldn't do the above
... a video element that is in the accessibility tree that is not in the DOM?? that doesn't make sense

<joanie> https://github.com/w3c/aria/issues/517#issuecomment-488837656

joanie: lets see if we have consensus on aria-playsmedia

canvas

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

Github: https://github.com/w3c/aria/issues/927

jamesn: do platform APIs have canvas?

joanie: yep

jamesn: maybe canvas sounds harder than it is

joanie: its kind of like I just proposed on the audio/video ticket
... this isn't a group in that it is not a block of text. So the question is do we want a canvas role? or do we want a canvas-y property?
... we already have ways to specify logic to say "if it is a role x and has aria attribute y then it is mapped to z"

melanierichards: role makes more sense to me

mck: the nice thing about the role approach is that you can make sure it doesn't inherit a bunch of junk

<joanie> https://trac.webkit.org/browser/webkit/trunk/LayoutTests/platform/mac/accessibility/roles-exposed-expected.txt#L67

joanie: this to me means canvas is not exposed on a mac

mck: are there elements that can go in a canvas?

jamesn: anything

joanie: thats the fallback content

mck: doesn't that mean we could just map it to a generic since its just a container

carmacleod: would you want to label it?

mck: generics don't get exposed like that

jamesn: they often do get exposed

mck: only if they're focusable
... we're diving off into generic - let's not do that

accName

https://lists.w3.org/Archives/Public/public-aria/2019May/0000.html

<melanierichards> scribe: melanierichards

(link contains Bryan's proposal for discussion)

bgaraventa1979: both how to simplify and how to restructure/make the algorithm clearer going forward. I'm trying to prepare for rewriting AccName 1.2. I want to be completely clear on the rules we're talking about

joanie: from quick skim seems good, need to reread
... this would be a basis of how to simplify, but not a replacement of the algorithm?
... this will help clarify the actual algorithm in my head, +1 for continuing in this general direction. I'm sure there will be wordsmithing

mck: putting the whitespace things into these rules instead of the algorithm itself, that essentially govern the algorithm, should make the presentation of the algorithm easier
... first you have to start out with a definition of terms

bgaraventa1979: haven't bothered with that part yet

mck: I don't understand part starting with "The aria-labelledby and aria-describedby attributes can only be processed..."

bgaraventa1979: you only process once, if you have something pointing via an aria-label, and that is pointing to another thing via aria-label, you'd only process that once. You can't have infinite recursion of aria-labelledby

mck: thinking of the simplest case. the input has aria-labelledby on it, it points to something that doesn't have content but has aria-labelledby on it which points to a label element...the input is the thing you're trying to label, so that's the root node. So when the current node becomes the empty div, it says this rule won't process the aria-labelledby

bgaraventa1979: correct
... it would be a blank AccName
... you could use aria-owns, which acts differently

mck: I didn't realize you couldn't change aria-labelledby

joanie: I thought so too
... what step in the spec prevents that?

[giggling about "otherwise"]

joanie: 2b
... first bullet

on board via mck: <div role="button"><span aria-labelledby="self myheading">actions for:</span></div>, and you're expecting to get "Actions for search results"

(assume that span also has id "self")

bgaraventa1979: you'd need to put the aria-labelledby on the button

joanie: but is that in the spec?
... we've set root node for the button, computing for the button, I think we hit 2F
... 2F iii
... so now we're going back to step 2 with our span, the current node has an aria-labelledby, and it's not already part of an aria-labelledby traversal. In that case, root node DNE current node and we still have to do the aria-labelledby traversal

bgaraventa1979: we'll have to check implementations, if they're doing this

joanie: I'm pretty sure some of them are
... current node means node in the HTML-y sense of the word, not an accessible object

mck: it hasn't been made clear to me what's a node in this spec. A DOM node?

joanie: yes

mck: so if we're talking DOM nodes, then this should work

(mck and joanie agree this doesn't jive with Bryan's text)

joanie: and maybe spec should be simplified so it isn't that way, but it's not now

(everyone is confused by the algorithm)

bgaraventa1979: it sets the current node to the root node at the beginning. Then the spec text says that in the absence of aria-labelledby, to precede to the next step below that, to continue down...from what I understood, it was starting at the level of the aria-label that child nodes were supposed to start at, not aria-labelledby. Trying to figure out where it says that
... that's how Joseph explained it to me back then

joanie: could be it wasn't understood then either, or things changed

HarrisSchneiderman: I tested our example in Safari and it calculated as expected, "Actions for: search results"

mck: the definition of aria-labelledby in the spec would make you think this works
... if there's a simple rule like this related to aria-labelledby that basically says you can't chain them together, the fact that we don't have that in the spec for the aria-labelledby definition, we ought to add an authors should not do this because it won't work
... aria-labelledby on the root node always works, it's when it's not on the root node....what's an example of when aria-labelledby is part of the traversal and it would fail? more than one in the chain?

bgaraventa1979: yeah it would only do the first one and then stop. To me it doesn't make sense to let it work not on the root node

mck: in the case of aria-labelledby, because the button is labeled by contents, the aria-labelledby is augmenting the contents

bgaraventa1979: what I'd suggest is not to allow embedding aria-labelledby and aria-describedby
... if you allow one to be processed internally, you have to allow the other one

mck: but descriptions are not calculated by the content. If you put aria-describedby on the span there's no reason to think it would work

jamesn: no recursive describedby

bgaraventa1979: sure, what I'm saying is to me it's equally confusing.

mck: you're talking about a person who knows about the existence of both things. If you're just an author on the street, if you looked at this you would think it's 100% logical. You wouldn't be thinking about aria-describedby at all, probably

bgaraventa1979: it seems way too easy to fall in the trap of author error. I've seen people use them inside everything.

mck: I guess I could see why somebody might say, I'm labeling a heading, and I want to provide additional content for SR users only, using aria-labelledby pointing to a hidden div or an image labelledby content outside of the heading....

bgaraventa1979: let's say there's a button with a span in it, and span points to aria-owns, and that aria-owns has an aria-labelledby...aria-owns is different
... describing this in a way that makes sense is not going to make the spec simpler

mck: I'm a little bit concerned that if this works right now, and it is because the way the algorithm is currently documented, and we yank that out, it's not obvious how you'd modify the algorithm itself. We'd have bugs in browsers who have faithfully documented the algorithm

bgaraventa1979: the fact that we are changing aria-label and aria-labelledby to not be global....

mck: still global, just with exceptions (gives examples)
... this would actually break if we disallowed aria-labelledby on a generic

HarrisSchneiderman: should the algorithm be aware of all the nuances?

mck: so if we disallowed on generic, then this particular example would break

joanie: that makes me happy
... if we're doing name from content, that should be contents. Just contents.

mck: good

joanie: if author wanted name from author, they should stick aria-labelledby on the button

bgaraventa1979: I'm confused on what people want

joanie: bryan's language will boil down to "name from contents means name from contents"

mck: button has name from contents, and the button has something inside that's generic

carmacleod: what happens if there's an SVG child of the button?
... I see that all the time

jamesn: aria-labelledby is fine on image

HarrisSchneiderman: exceptions for aria-label and aria-labelledby in the AccName algo seems like a weird thing to keep in sync

audio/video role parity

jamesn: we'd like the rationale behind your strong opposition to audio/video roles

jcraig: I believe I filed this under the premise of reserved roles, like native-*

jamesn: we're wondering why we can't have an audio or video role
... what's the difference b/t that and everything else in ARIA

jcraig: each of those comes with API support. When you have a video element, it can be controlled and queried programmatically. Standardized JS APIs for these different interfaces, which can't be queried with a div that has video role on it. Until we get the point where we provide the author a way to say, here I've got these delegates that can respond to different requests for audio/video controller...play key on Mac will bind to play/pause...
... ...in native element, but not in div with role on it

jamesn: sure, but does a11y API have the ability to do that, or just the standard JS APIs? I don't understand how it's different from any other role in that you'd have to write it yourself as a JS developer

jcraig: trying to solve similar problem with sliders. No way for touch screen to interact with the slider control. All of these other APIs like audio and video have significantly more complexities than supporting a slider.

jamesn: essentially on iOS, if you have a video element, there are gestures that the a11y API can send to the control (play, pause, increase volume)

jcraig: not limited to a11y API
... however the user wants to control it, that's not something that ARIA can copy

jamesn: if somebody does this today and creates a video out of something else, which they do, they don't get any of that functionality anyway, and they aren't able to say it's a video. I don't want to encourage it, but if we don't have a role, we can't expose details. If we did have one, we could

jcraig: when we pass things through the native accessibility role, there are expectations that the user has. A user of a video would expect that the video would respond to their prefs for autoplay, for caption settings, etc
... by calling it video, user isn't gaining anything, we're potentially confusing them more

joanie: aren't we already in the danger of that happening if the author puts aria-roledescription="video" on this hypothetical custom video control?

jcraig: sounds like a good enough workaround
... preferable to an ARIA API that doesn't actually work

joanie: I was meaning that would already impart confusion on the user, told something is a video but it's not
... I put in issue #517, a possible other way forward
... I want to complete role parity to best of our ability. If a screen reader knows that something says it's an audio or video player, they might want to adjust their behavior. A non-parseable roledescription is not going to work
... we can get partial parity via the group role. I don't think a player is like a div/span, but it is a group with UI components inside. Second part would be not an ARIA role...

jcraig: reads in issue about aria-playsmedia

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

jcraig: I filed a similar issue a couple years ago. If that were the case it should go on the button instead of the video itself
... one of the reasons for 1:1 role parity is to use WPT to ensure browser compat [paraphrased]
... if we don't think video is something that an author should use as a role, but we do agree that the native video element should return the same thing from various implementations, return some like native-audio, native-video

joanie: would not do anything for custom components, right?

jcraig: for custom components, opening up video API to apply to custom components. If that happens, fine to open up video role

mck: so you're saying you don't want more of the slider problem

jcraig: yes
... most web devs can make a very accessible video player without using a video role
... I've worked on a web player...the native player in WebKit is all rendered in JS

jamesn: but this applies to anything we're doing with role parity, you can use HTML to use the same experience

jcraig: main thing that's different about these, these are not implementable

jamesn: is there any advantage to doing anything with these?

joanie: aside from letting SRs know what these are, no

jcraig: with native-*, we can all agree how web platforms should be testable with WPT

mck: instead of using something like native-* role name to do that, would it be fine for us to give audio/video generic role, and then give it a specific attribute? I don't think namespace sits well with everybody. mediatype attribute, with values like audio or video. or hasmedia, with values audio or video.

jcraig: people are opposed to defining a native role that would be in the spec. I would expect that the spec would define it when the host language has something that can't be implemented [paraphrased]

jamesn: maybe in HTML-AAM, say no equivalent in ARIA

jcraig: probably want to standardize the pattern in ARIA, certainly not the specific roles

joanie: I don't think it's ARIA's place to define how other languages return roles for automated testing and WPT
... I think it's a fine approach but not our place to define
... the one thing I think we have consensus on is we're not going to do audio, video roles until the API opens up

(joanie types into issue)

<Zakim> jcraig, you wanted to explore the namespaced idea some more

jcraig: I like what Matt threw out, pseudo namespace. html:video, mathml:frac. I know there's been previous objections to namespaces in ARIA
... I'd be perfectly happy with that instead of native-* prefixing
... not say role="html:video", just the response, the computed role

mck: are you still thinking this falls within the user agent portion of the ARIA spec? If you were going to put something in the ARIA spec, it's not part of IDL, where would it go?

joanie: it's not going to be in ARIA

jcraig: talking about this as part of AOM
... pretty much every implementer is in agreement that we shouldn't open up computed role to author, too hard to extract
... pretty much every implementer agrees would be useful for test context (Web Driver, WPT)
... we could have a centralized repository of JS-based tests that would allow ARIA and other spec devs to determine that things are computed identically between browsers
... wouldn't be available to the web page to check
... where it lands....Web Driver, maybe AOM, maybe ARIA. Hard to say. Role parity is a precursor to that ability, I believe. We have to have parity on what the roles should be before the right tests can compare browsers

mck: for these elements, if ARIA says there will be no corresponding role, what AOM gets in response to computed role from the browser, what spec would specify what it gets back from the request?
... for us that would end up being nothing to do with audio and video for ARIA 1.2
... thinking about where it should go is important, but some people here don't want to put brainpower behind thinking where it goes

joanie: if it's not going to be something that ARIA controls or maintains, I'm happy to participate if people want to brainstorm...I don't mean it dismissively, but it's not our domain
... should be standardized somewhere, I don't know where, but it's not ARIA

jcraig: a decision is probably required to achieve what we have been calling role parity

mck: decision could be no corresponding role

joanie: or group

mck: but you can't tell the difference from other groups

jamesn: we don't want to tell people it's a group when it's a video. I'd prefer mapping to nothing

joanie: I can live with that

jamesn: testing can deal with what they return if there's no mapping

jcraig: I want to avoid some web authors saying "we made our player accessible because we used the video role" and actually it's a pile of junk. Making this all accessible is non-trivial. And then there's all these APIs like play and pause that are reserved for video controls.

<joanie> https://github.com/w3c/aria/issues/517

<joanie> I believe we're blocked until the native APIs for video and audio are something which authors and ATs can utilize so that custom players behave in exactly the fashion as native ones.

joanie: added new comment
... does that capture your concerns?

jcraig: yes

<jcraig> ack //

mck: if an author is making their own player for another reason, the roledescription workaround...they can do that, it won't work like a native video, but it also won't be reported as a native video when you ask for the computed role. So that seems fine to me.

<harris> ack html:video

mck: we avoid slider problem

<harris> shrug indeed

<jcraig> ack "

mck: in some spec, probably not ARIA, say what gets returned for the computed role. If we ever put a custom video player in the authoring practices, which I don't think we'll bother to do (though it's in the backlog), we'd use roledescription

(group agrees)

jamesn: could close as won't fix, and if something changes we can re-open

<jcraig> I had forgotten that Alice had also suggested the namespaced approach. Evidence: https://github.com/w3c/aria/issues/529#issuecomment-437093886

<jcraig> Github: https://github.com/w3c/aria/issues/529#issuecomment-437093886

ARIA Face to Face Day 3

02 May 2019

Attendees

Contents