See also: IRC log
<scribe> agenda: this
<joanie> scribe: joanie
<clown> https://github.com/w3c/aria/issues/513
<clown> https://github.com/w3c/aria/issues/513#issuecomment-273817749
JS: Joanie raised this issue
against Core AAM.
... It's about role region when it doesn't have a label.
... In that case, it shouldn't be treated as a landmark.
RS: That's true.
JS: But the Core AAM doesn't handle that.
RS: It should.
JS: Agreed. See the comment in
the URL above.
... I've since opened an issue against HTML AAM.
... So that they treat regions without labels as if they were
divs.
RS: I thought they fixed that.
JS: What they did is left it up to screen readers to do this check and filter.
<clown> https://github.com/w3c/html-aam/issues/79
RS: Maybe because of JAWS. I think JAWS has such a check.
JS: The URL above is for the
issue I filed.
... I also mentioned you (Rich).
JD: Regarding Rich's comment that JAWS's check was why HTML AAM took this approach: You are correct, JAWS's check was explicitly cited by Steve in rswponse to my comment.
JS: So what I'll put in the Core
AAM is to map ARIA role region to the native host language
semantic if there is no accessible name.
... And section without an explicit role as github issue
79.
... Where do we put the action for the test item?
RS: I have been working on writing test cases.
<clown> https://www.w3.org/wiki/ARIA_1.1_Testable_Statements#region
JD: Since this is Core AAM and not the ARIA spec itself, should we put these sorts of tests in a separate area or otherwise make it clearly marked?
RS: I'll make a special section
for it on the wiki (URL above).
... If you look at the harness page now, there's a special
section for Core AAM.
<clown> https://github.com/w3c/aria/issues/514
<clown> https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-form
JS: There is someone from TPG (Matthew) who has opened the above issue for the similar case with forms.
<clown> "IA2_ROLE_FORM + object attribute xml-roles:form"
<clown> ATK: ROLE_LANDMARK + object attribute xml-roles:form
<clown> https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-form
JD: So clarification: The above text from Joseph is in the case of role="form" regardless of whether there is a name or not?
JS: Yes.
JD: So this really is just a different flavor of the region without a name situation?
JS: Yes.
... Do we want to solve it now?
<clown> scribenick: clown
JD: so, a region with a name is a landmark, but a region without a name is not..
RS: There's a reason for that because people were making regions as if they were navigable chunks.
JD: I don't understand what is different about a form.
RS: It's different because there
is structured data associated with a form that get
submitted.
... that is not true of a region.
JD: There were cases where forms were badly used, say when the entire page is a form.
RS: So? You could be the entire
landmark on the entire page, and be done.
... Also, you could give a name to the form, and it would still
be bad.
JD: Even if we don't fix this in the Core-AAM, it should be addressed in the HTML-AAM
JS: Matthew has opened such an issue against the HTML-AAM
RS: I don't agree with Matthew here.
JD: I do agree with him with
respect to the <form> element.
... If there are a lot of nameless <section> elements,
orca says, "region, region, region, …."
... I've added a hack to take care of this for <section>,
and I think I would do the same for <form>
RS: If we are talking about a form, then you still want to indicate that it is a form. It has special functionality that needs to be communicate.
<joanie> scribe: joanie
<clown> JS: BTW, in the the core-aam mappings its only UIA and ATK/AT-SPI that maps role form to landmark.
JS: So the only ones we really have to worry about is UIA and ATK.
RS: For?
JS: The form role.
... How do you know you're in a form in AXAPI?
JD: Maybe there's a subrole?
JS: Not mentioned in the Core AAM, but there might be one.
RS: We should be able to check.
JS: Let me try.
JD: Should we open an issue against Core AAM to verify the AXAPI subrole, etc.?
JS: We have tests for that, but I
may look into it more.
... What should we do about form for ATK?
JD: I'm fine with either, but I
want the mappings to reflect what the expected screen reader
(i.e. Orca) behavior is.
... If Orca should treat it as a landmark, expose it as
ROLE_LANDMARK.
JS: There were a bunch of AXAPI
issues.
... We went though many of them last time.
... The decision was to do the rest via testing to reveal the
answer.
<clown> https://github.com/w3c/aria/issues/459
<clown> https://github.com/w3c/aria/commit/f4c807710bf1131aa3f460b0719e3aa996dc0f3d
JS: Also, since Joanie has to do
the WebKitGtk implementation anyway, she might be able to
implement anything which is not yet implemented for
Safari.
... I have closed issue 459.
<clown> https://github.com/w3c/aria/issues/464
JS: I have also closed issue 464
(related to aria-roledescription with an empty string)
... This condition is not explicitly mapped, other than as an
author error.
... This will also be revealed through testing.
... Any thoughts on any of that?
RS: I don't think they wanted to
see it mapped.
... Matt and Joanie were very clear about that.
... I think Bryan felt the same way as well.
<clown> <div aria-roledescription="button">
RS: I understand their reasoning, and since I don't live with it every day, I'll defer to them.
JS: Is the above valid as a test case?
JD: But I thought you said issue 464 was about a roledescription value that was an empty string.
JS: Ah, so this is another concern mentioned by James in this issue.
RS: I can see James' point.
... And the assumption is that we will have one-to-one
correspondence between native elements and ARIA roles.
<clown> https://rawgit.com/w3c/aria/master/aria/aria.html#aria-roledescription
RS: We don't yet have that. This is one of the main reasons we're planning on an ARIA 1.2.
<clown> "The element to which aria-roledescription is applied does not have a valid WAI-ARIA role or does not have an implicit WAI-ARIA role semantic."
JS: The above (from the spec) indicates that the meter element without a role specified cannot use aria-roledescription.
<clown> https://bugs.webkit.org/show_bug.cgi?id=163647
JD: I agree with James'
suggestion that the concern is things like <div
aria-roledescription="button">.
... Because the above maps to ROLE_SECTION, so Orca has no way
of knowing it's a button.
... In the case of the meter element, I know it's
ROLE_LEVEL_BAR, and thus don't need an explicit or implicit
ARIA role.
... If we weren't in CR, I'd want to make the modification to
the spec to make the restriction apply to just generic elements
(as James suggested).
RS: Agreed. But we're in CR. We
can mark it at risk.
... Do we want to mark it at risk?
JS: No.
... I want a test case.
... Do you really think we'll not have enough
implementations?
... I don't think Safari will implement this restriction; but
what about Chrome and Firefox?
... Unless we believe they won't either, I think it's premature
to mark this as at-risk.
... I'll test this in Firefox, at least.
JD: Test nightly.
... We won't know, however, if the exposure (e.g. via object
attribute) is the result of refusal to implement, or the result
of the default expose-everything via object attribute.
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/item./item?/ Succeeded: s/form?/form for ATK?/ Succeeded: s/implementations./implementations?/ Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Found Scribe: joanie Inferring ScribeNick: joanie Found ScribeNick: clown Found Scribe: joanie Inferring ScribeNick: joanie ScribeNicks: clown, joanie Default Present: Joanmarie_Diggs, Joseph_Scheuhammer, Rich_Schwerdtfeger Present: Joanmarie_Diggs Joseph_Scheuhammer Rich_Schwerdtfeger Found Date: 24 Jan 2017 People with action items:[End of scribe.perl diagnostic output]