– DRAFT –
ARIA WG

New Issue Triage

<daniel-montalvo> James: HTML-AAM #489

<daniel-montalvo> Scott: already responded. Something that should probably updated in ARIA 1.3 for generic

<daniel-montalvo> ... If many HTML elements don't map to generic I am not sure where they should be mapping to

<pkra> +1

<daniel-montalvo> ... It's either they are not mapped or they are presentational

<daniel-montalvo> ... IF they have some properties like aria-live they become generic,

<daniel-montalvo> Jamesn: Are you volunteering?

<daniel-montalvo> Scot: Yes, I'll write some text for this

<daniel-montalvo> JamesN: Let's agenda it for later just to make sure we don't miss anything

<daniel-montalvo> JamesN: ARIA #943

<pkra> my mic is failing me.

<pkra> I think it was just a question.

<daniel-montalvo> Scott: Peter's response makes sense here, there is potential clarifications we can make, mainly editorial changes

<pkra> I don't think it needs a clarification.

<daniel-montalvo> JamesN: Does anyone want to clarify or we should close it?

<daniel-montalvo> Peter: I think it is a newly question, agree we should be closing it

<daniel-montalvo> S/newly/newby/

<daniel-montalvo> JamesN: ARIA #1942

<daniel-montalvo> ... Something we should take on our Editors call, We are not meeting this Monday though because of holidays

<daniel-montalvo> JamesN: There is already precedent in using ARIA stuff for other than accessibility

<daniel-montalvo> Scott: Seems like a very weird change. We can create synonyms for things, otherwise that's going to break stuff

<daniel-montalvo> Peter: IF HTML had something posinset I would be happy. Sure there are properties that should be more general but there's where HTML comes

<daniel-montalvo> JamesN: It may not be HTML though

<daniel-montalvo> ... Potentially they are creating something and that's why they want to reuse what we already have in here

<daniel-montalvo> Peter: We'd need a Deep Dive

<daniel-montalvo> JamesN: Anyone want to contact this person and find out more?

<daniel-montalvo> JamesN: Seems like a Deep Dive / TPAC conversation

<daniel-montalvo> Peter: Even a TAG conversation

New PR Triage

New Issue Triage

<daniel-montalvo> JamesC: There is more than what's on this list

<daniel-montalvo> JamesN: This is sort of editorial,Dainel, can you take a look at this?

<jamesn> w3c/graphics-aam#11

<daniel-montalvo> Daniel: Sure

<daniel-montalvo> Peter: There is an AAM PR from you JacesC, right?

<daniel-montalvo> JamesC: You are right. An editorial typo

New PR Triage

<daniel-montalvo> Andrea: JamesN: Purely editorial

<daniel-montalvo> Andre: Yes,

<daniel-montalvo> S/Andrea: James:/James:/

Windows/Mac differences in presentation of some HTML-AAM implicit roles

<daniel-montalvo> JamesN: I don't know what we need to do with this. I feel like there are some issues as Sarah and jaws-test stated

<daniel-montalvo> ... a button where you can choose a value can potentially be invalid and have error messages associated. You could be required to select a value, there is value on putting these in this control, but the button do not support it

<daniel-montalvo> JamesC: I think we forgot to remove this from the agenda. Agree that this is a hard problem

<daniel-montalvo> JamesN: Deep Dive?

<daniel-montalvo> JamesC: Maybe

<daniel-montalvo> JamesN: It requires some proposed solution to bring it to Deep Dive

do we need a focusable definition

<jamesn> https://w3c.github.io/aria/#conflict_resolution_presentation_none

<daniel-montalvo> Peter: This came up in the editors meeting because there was a stale PR in aria-commons and we decided it did not belong there anymore. It is unclear which definitions to use there.

<daniel-montalvo> JamesN: We say "focus" but we don't really say what we mean. There are 58 instances of this in the spec. We could create a definition that points to the host languages. There are definitions in SVG

<daniel-montalvo> ... HTML doesn't really have a good definition, it talks about "focusable area", not sure it this is the same

<daniel-montalvo> ... I don't agree with "href depending in platform conventions"

<daniel-montalvo> JamesC: Any AT can focus anything that is facesable

<daniel-montalvo> S/facesable/focusable/

<daniel-montalvo> Matt: Are all of these terms normative?

<daniel-montalvo> DanielP: I think there is no real HTML focus in an element when using VoiceOver

<daniel-montalvo> JamesC: If it is focusable in any mechanism and you land it with an AT on a Mac, the DOM focus will follow the AT cursor

<daniel-montalvo> ... Unless you've turned on a non-default setting in VoiceOver

<daniel-montalvo> Matt: It is quite different from JAWS

<daniel-montalvo> DanielP: Is that the default setting?

<daniel-montalvo> JamesC: Yes, it is in the navigation tab and it's on by default

<daniel-montalvo> Matt: If it is in normative statement that increases the need. Curious if that creates ambiguity

<daniel-montalvo> ... When we say "focusable" in ARIA we really mean "focusable" in the user agent, it does not have to do with AT

<daniel-montalvo> JamesC: And it does not n3cessarily mean tab-focusable

<daniel-montalvo> JamesN: That's the clarification we need

<daniel-montalvo> ... It 's more than just tab-focusable

<daniel-montalvo> Matt: That would be good, we. Have been putting notes all around in APG to explain this

<daniel-montalvo> JamesN: Would it be worth for us to try an write a definition?

<daniel-montalvo> JamesC: Yes, put me in for that. I think we need to point to the HTML definition but add some accessibility specifics for that

<daniel-montalvo> JamesN: Does AT focusable have an impact on where we use "focusable"?

<daniel-montalvo> JamesC: I don't think so but it would be beneficial for readers if we provide an explanation

<daniel-montalvo> Matt: Especially for active-descendant contexts

<daniel-montalvo> JamesC: Probably we need three terms: tab, AT, and DOM focusable

<daniel-montalvo> Matt: We have tubbable in APG and we distinguish it from DOM focusable in some places. I think there is some value in these two terms.

<daniel-montalvo> JamesN: I do see "keyboard focusable" in other places. We have

<daniel-montalvo> ... We might have to change the words in these places

<daniel-montalvo> Matt: I don't know if it causes confusion. It came up because some authors found it confusing.

<daniel-montalvo> JamesN: For example, why is something that I take out of the tab sequence triggering role conflict resolution? That is easy to ex plain, but still somewhat confusing.

<siri> https://www.w3.org/TR/wai-aria-1.2/#dialog

aria-haspopup

<daniel-montalvo> Siri: aqria-haspopu has been deprecated for buttons, but when I go to the spec it still shows up for buttons

<daniel-montalvo> JamesN: That was global now it's only allowed in certain context

<daniel-montalvo> Siri: Can I use this for buttons?

<daniel-montalvo> Matt: We have not disallowed it, we have advice against it in APG

<siri> https://www.w3.org/TR/wai-aria-1.2/#aria-haspopup

<daniel-montalvo> .. I have on my to-do list to qualify this and only allow true, false , and menu values

<daniel-montalvo> Mario: On Windows, if a button opens a dialog, they use "..."

<daniel-montalvo> ... Screen readers could do something with these

<daniel-montalvo> JAmesN: that was the original intent

<daniel-montalvo> Matt: Not when we put it in 1.1

<daniel-montalvo> ... The original intent was for combo boxes

<daniel-montalvo> JamesN: Maybe we should finally look at Scott's issue to resolve aria-haspopup

<daniel-montalvo> Matt: We targeted it for 1.4

<jamesn> w3c/aria#1024

<daniel-montalvo> JamesN: 1824, 999, and others discuss this largely

Quick note on WPT breakage

<jcraig> web-platform-tests/wpt#40188