W3C home > Mailing lists > Public > public-aria@w3.org > January 2017

[AAPI] Minutes UIA TF Meeting Tuesday, 24 January 2017

From: Joanmarie Diggs <jdiggs@igalia.com>
Date: Tue, 24 Jan 2017 22:25:18 +0100
To: ARIA Working Group <public-aria@w3.org>
Cc: "wai-xtech@w3.org" <wai-xtech@w3.org>
Message-ID: <7b69a4a4-5580-bc2d-6ea9-b893c54bb75c@igalia.com>
Link: https://www.w3.org/2017/01/24-aapi-minutes.html

Plain text follows:


      [1] http://www.w3.org/

   Accessible Rich Internet Applications Working Group Teleconference

24 Jan 2017

   See also: [2]IRC log

      [2] http://www.w3.org/2017/01/24-aapi-irc


          Joanmarie_Diggs, Joseph_Scheuhammer, Rich_Schwerdtfeger




     * [3]Topics
         1. [4](All) update on AX API GH-ISSUEs
         2. [5]GH-ISSUE-513: (All) Mapping of role="region" when
            it doesn't have an accessible name.
         3. [6](All) update on AX API GH-ISSUEs
     * [7]Summary of Action Items
     * [8]Summary of Resolutions

   <scribe> agenda: this

   <joanie> scribe: joanie

(All) update on AX API GH-ISSUEs

   <clown> [9]https://github.com/w3c/aria/issues/513

      [9] https://github.com/w3c/aria/issues/513


     [10] 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

   RS: I thought they fixed that.

   JS: What they did is left it up to screen readers to do this
   check and filter.

   <clown> [11]https://github.com/w3c/html-aam/issues/79

     [11] 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
   ... 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.


     [12] 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> [13]https://github.com/w3c/aria/issues/514

     [13] https://github.com/w3c/aria/issues/514



   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



   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

   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

GH-ISSUE-513: (All) Mapping of role="region" when it doesn't have an
accessible name.

(All) update on AX API GH-ISSUEs

   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

   <clown> [16]https://github.com/w3c/aria/issues/459

     [16] https://github.com/w3c/aria/issues/459



   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> [18]https://github.com/w3c/aria/issues/464

     [18] 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

   RS: I can see James' point.
   ... And the assumption is that we will have one-to-one
   correspondence between native elements and ARIA roles.



   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> [20]https://bugs.webkit.org/show_bug.cgi?id=163647

     [20] 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.

Summary of Action Items

Summary of Resolutions

   [End of minutes
Received on Tuesday, 24 January 2017 21:26:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:36 UTC