W3C home > Mailing lists > Public > public-aria@w3.org > March 2016

[AAPI] Minutes UAI TF Meeting, Tuesday 29 March 2016

From: Joanmarie Diggs <jdiggs@igalia.com>
Date: Tue, 29 Mar 2016 16:11:22 -0400
To: ARIA Working Group <public-aria@w3.org>
Cc: "wai-xtech@w3.org" <wai-xtech@w3.org>
Message-ID: <56FAE16A.1090607@igalia.com>
URL: https://www.w3.org/2016/03/29-aapi-minutes.html

Plain text follows:

   [1]W3C

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

   Accessible Rich Internet Applications Working Group Teleconference

29 Mar 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/03/29-aapi-irc

Attendees

   Present
          AmeliaBR, Cynthia_Shelly, Joanmarie_Diggs,
          Joseph_Scheuhammer, Rich_Schwerdtfeger

   Regrets
   Chair
          Joseph_Scheuhammer

   Scribe
          joanie

Contents

     * [3]Topics
         1. [4]ACTION-2008 (Cynthia/Joseph) Handle concept of
            description property for UIA.
         2. [5]ACTION-1681 (All) Clarifying inclusions rules
            and/or exclusion rules.
     * [6]Summary of Action Items
     * [7]Summary of Resolutions
     __________________________________________________________

   <clown> agenda: this

   <scribe> scribe: joanie

ACTION-2008 (Cynthia/Joseph) Handle concept of description property
for UIA.

   <clown> action-2008?

   <trackbot> action-2008 -- Joseph Scheuhammer to Handle concept
   of description property for UIA -- due 2016-03-01 --
   PENDINGREVIEW

   <trackbot> [8]http://www.w3.org/WAI/ARIA/track/actions/2008

      [8] http://www.w3.org/WAI/ARIA/track/actions/2008

   JS: There is going to be a description property in UIA, like
   there is in the other platforms.

   (Group discusses how to do pull requests)

   <clown>
   [9]https://rawgit.com/w3c/aria/action-2008/core-aam/core-aam.ht
   ml#ariaDescribedBy

      [9]
https://rawgit.com/w3c/aria/action-2008/core-aam/core-aam.html#ariaDescribedBy

   JS: The above URL is for the change.

   RS: I'm pleased at this new property.

   CS: We also have help text.
   ... Which is for things which are not descriptions, but
   otherwise helpful.

   RS: Can we put errormessage in help text?

   CS: It's usually for things like tooltips.

   ABR: In the name and description calculation, if the API/AT has
   a way of presenting both description and tooltip, this will
   preserve each.

   CS: I don't know if the other platforms have a way to do that.
   ... But we do.

   JS: If it's not already in master, I'll put it there.

   CS: If I put it in master, I'm not sure how I did it.

   JS: I'll check, and I'll close the action.

   CS: While I was working on that, I made an action for myself to
   add this to AccName AAM.
   ... I think that's a bit more complicated.

   action-1104

   <trackbot> action-1104 -- Cynthia Shelly to Define what the
   accessibility API mapping is for UIA on aria-describedby in
   section 5.5.1 table when the element does not exist in the
   accessibility tree such as when css: display:none applies --
   due 2016-12-31 -- CLOSED

   <trackbot> [10]http://www.w3.org/WAI/ARIA/track/actions/1104

     [10] http://www.w3.org/WAI/ARIA/track/actions/1104

   JS: That is action-1104

   CS: I'm doing a bunch of AccName changes.

   JS: You closed it as a duplicate.

   CS: There's another one too.
   ... I'm thinking of action-2042.

   action-2042

   <trackbot> action-2042 -- Cynthia Shelly to update accname-aam
   to reflect UIA FullDescription -- due 2016-04-25 -- OPEN

   <trackbot> [11]http://www.w3.org/WAI/ARIA/track/actions/2042

     [11] http://www.w3.org/WAI/ARIA/track/actions/2042

   CS: And that's a little more involved.
   ... I'm doing some other work, but didn't finish it before
   CSUN.

   <clown>
   [12]https://rawgit.com/w3c/aria/master/accname-aam/accname-aam.
   html#accessible-name-and-description-mapping

     [12]
https://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html#accessible-name-and-description-mapping

   JS: Look at the table (above URL), under accessible
   description, there's a TBD under UIA.

   CS: Action 1104 was just about aria-describedby.
   ... This (other action) involves looking through all the places
   where changes might be needed.
   ... I also need to think about what impact having three fields
   has.

   JS: I'll keep an eye on what you're doing.

   CS: I'll have a sizable pull request for you.

   JS: Other questions?

ACTION-1681 (All) Clarifying inclusions rules and/or exclusion rules.

   <clown> action-1681

   <trackbot> action-1681 -- Joseph Scheuhammer to Propose new
   wording, as an editorial change only to clarify the inclusion
   rules in section 5.1.2 -- due 2015-09-15 -- OPEN

   <trackbot> [13]http://www.w3.org/WAI/ARIA/track/actions/1681

     [13] http://www.w3.org/WAI/ARIA/track/actions/1681

   JS: This is a continuation from last meeting.
   ... We stopped at the case where you have an event handler on
   the body which handles all click events on the document.
   ... And what the means for inclusion in the accessibility tree.

   <clown>
   [14]https://lists.w3.org/Archives/Public/public-aria/2016Mar/01
   59.html

     [14] https://lists.w3.org/Archives/Public/public-aria/2016Mar/0159.html

   JS: Rich sent email (link above) to Alex.
   ... (Reads from the aforementioned email)

   <clown>
   [15]https://lists.w3.org/Archives/Public/public-aria/2016Mar/02
   15.html

     [15] https://lists.w3.org/Archives/Public/public-aria/2016Mar/0215.html

   JS: Alex replied (above URL)
   ... Which I sort of understand, but not completely.

   RS: (Reads statement from Alex's email)

   JS: For this particular condition, it just exposes the leaves.

   CS: Does it cause other elements which wouldn't normally be in
   the tree to be there?

   RS: I don't think so.

   ABR: If the leaf node is an em element or span, that would add
   a lot of clutter.

   CS: I think we're not going to expose every element in the DOM.
   ... If there's an event handler like onclick on the body, we'll
   handle it a different way.

   Group: It's expensive.

   JS: If I read him literally, he's not talking about the span,
   but the text in the span.
   ... Is that the correct interpretation?

   RS: Like CDATA?
   ... We can ask him.

   CS: It would be good to contact him to clarify.

   RS: I'll respond to him.

   JS: (Reads from Alex's response)

   RS: I believe when he said "I think", he didn't look.

   JS: But I did (look).
   ... What you have to do is put a click handler on the input
   element to cancel the bubbling.

   RS: I'll include that in my response.

   JS: Mind you, I only tested Firefox.

   RS: Any particular version of Firefox, Joseph?

   JS: Whatever was the latest version as of last week.

   RS: Email sent.

   JS: Does that answer our question, then?

   RS: He didn't quite answer it.

   CS: I think it's pretty clear that we don't want to require
   browsers to do that.
   ... It sounds like if there's things already in the tree,
   they're exposing the action on those objects.

   ABR: So as far as the spec, we want to make it clear that we'll
   not be adding extra nodes to the accessibility tree as a result
   of global or inherited onclick handlers.
   ... If you add one to a specific node, then that node needs to
   be in the tree?

   CS: I think that's an open issue, along with how to handle the
   global element?

   JS: For instance, if it's on the body.

   CS: Body might not be a good example; if the global handler is
   on a div or span.
   ... In that case, we would include it.

   ABR: It might result in something with role="presentation"
   winding up in the tree.
   ... But we need to clear that up in the Core AAM.

   CS: It's not all event handlers; it's just click.
   ... We don't want all event handlers in the tree.

   ABR: And key handlers are covered by focusability.

   CS: Touch handlers we treat as click.
   ... We can look at if we want to do W3C touch and pointer
   events.
   ... But I think those may be less common, or less urgent.
   ... And that we're fine for 1.1.
   ... But someone could look into it.

   JS: So you just want click handlers for now?

   CS: Yes.

   ABR: I would generalize that to touch or mouse event handlers.
   ... It would be strange if single click were treated
   differently than double click.

   CS: But that's device dependent.

   ABR: I guess the question is if it will be useful to expose it
   to the AT?
   ... If so, do we want an open-ended inclusion?
   ... In other words, if the AT can handle it.

   JS + CS: I think that's for 2.0.

   CS: This is risky stuff (for 1.1). But we might wish to dip our
   toe into it.

   JS: I think right now, only click is something the platform can
   handle.

   JS + CS: I like your idea.

   ABR: If we could come up with open-ended language that allows
   it.

   CS: I don't like open-ended.

   JS: We could add some sort of text which indicates we'll deal
   with it in future versions of ARIA.

   ABR: As far as authoring guidance goes, authors should not be
   relying upon event handlers to get something included in the
   tree.

   CS: We wired up click in Windows 10. And we did it because so
   many websites do not add the appropriate thing.
   ... We scoped it very tightly, however.
   ... What we found is that it helps in a reasonable number of
   cases.
   ... And didn't make the rest any worse.

   ABR: I think this is one of those things where the browser is
   trying to patch up authoring errors.
   ... Thus being conservative seems appropriate.

   JS: I will come up with some wording for global versus
   element-specific handlers.

   CS: There is certainly language out there for this.

   JS: I'll look around.

   <clown> issue-1017

   <trackbot> issue-1017 -- Separate out text from role="none" and
   "presentation" so that a single location may be referenced in
   Core-AAM -- open

   <trackbot> [16]http://www.w3.org/WAI/ARIA/track/issues/1017

     [16] http://www.w3.org/WAI/ARIA/track/issues/1017

   JS: I am waiting on issue-1017.

   JS (Describes issue)

   RS: If we apply a role to something inherited?

   JS: No, it's an author error.
   ... The concrete case is presentational role being used, along
   with a global ARIA property (e.g. aria-label).
   ... Where things override the presentational role is scattered
   throughout.

   RS: I thought we were going to put all the presentational stuff
   in a single section.

   JS: (Quotes the text in the issue)

   RS: That was right before we went to CSUN.

   JS: Yes.

   RS: Do I have an action?
   ... And it should go in the ARIA spec.

   JS: There is no action, and yes it will be in the ARIA spec.

   RS: We also have to deal with password and keyboard shortcuts.
   ... If you give me an action, I'll do it for the ARIA spec.

   <clown> ACTION: Rich to separater out text from
   role="presentation/none" so that a single location may be
   referenced in Core-AAM. [recorded in
   [17]http://www.w3.org/2016/03/29-aapi-minutes.html#action01]

     [17] http://www.w3.org/2016/03/29-aapi-minutes.html#action01]

   <trackbot> Created ACTION-2044 - Separater out text from
   role="presentation/none" so that a single location may be
   referenced in core-aam. [on Richard Schwerdtfeger - due
   2016-04-05].

   <clown> action-2044

   <trackbot> action-2044 -- Richard Schwerdtfeger to Separater
   out text from role="presentation/none" so that a single
   location may be referenced in core-aam. -- due 2016-04-05 --
   OPEN

   <trackbot> [18]http://www.w3.org/WAI/ARIA/track/actions/2044

     [18] http://www.w3.org/WAI/ARIA/track/actions/2044

   ABR: That's an action to clear up the ARIA spec.

   <AmeliaBR>
   [19]https://lists.w3.org/Archives/Public/public-aria/2016Mar/01
   58.html

     [19] https://lists.w3.org/Archives/Public/public-aria/2016Mar/0158.html

   ABR: For the Core AAM, there will be additional details
   regarding when things are conflicting.
   ... The URL above points to an email I sent a couple of weeks
   ago.
   ... Is this what everyone else understands?
   ... (Describes contents of email)

   (Group processes contents of email)

   CS: Number 1 is fine.
   ... I think I'd add tabindex of -1 to item 1.

   ABR: But what if it has aria-hidden on it because it's not
   relevant.

   CS: There are various reasons things go in (natively they go
   in, or their focusable, etc.)
   ... Tabindex of -1 falls into that category.
   ... But I see what you're trying to do.
   ... That item 1 applies even if it's hidden.

   ABR: You're (Cynthia) taking my list in reverse order, I think.

   <Rich> [20]https://www.w3.org/WAI/ARIA/track/actions/2044

     [20] https://www.w3.org/WAI/ARIA/track/actions/2044

   RS: Above is the new action.
   ... You'll see some text in there.

   JS: Amelia, is your email text the suggested text for Rich?

   ABR: This is something I'd like to see in the Core AAM.

   JS: And wipe out the text that is there?

   <clown>
   [21]https://rawgit.com/w3c/aria/action-2008/core-aam/core-aam.h
   tml#include_elements

     [21]
https://rawgit.com/w3c/aria/action-2008/core-aam/core-aam.html#include_elements

   ABR: I don't care as much as what is in there adds up to what's
   in my email.

   CS: I don't normally like algorithms in specs, but maybe this
   is an instance where we want one.

   JS: I put in the URL for the current inclusion (above).
   ... It's just a list.

   ABR: What brought up this issue is that it doesn't right now
   handle certain interactions between including and excluding.

   RS: And title?

   JS: That's part of HTML AAM; not Core AAM.

   ABR: I have it that role="none" takes precedence over native
   host language semantics.

   RS: So if someone puts a tooltip on there, we don't care?

   <cyns_> step 1: include based on native rules. Step 2: include
   things with roles (and the other properties) Step 3: remove
   hidden things Step 4: add back focusable and other override
   stuff

   ABR: If someone puts a caption on a table with
   role="presentation"

   CS: Above is a quick example of a algorithmic approach.
   ... (Reads)

   ABR: I think the only thing you're missing there are things
   which would normally be included due to native roles.

   CS: That's step 3, in my mind.

   ABR: No, because hidden overrides things which role="none" does
   not.

   CS: I meant to include those in step 3
   ... That makes it clear what goes in and out.
   ... I'm not sure if it's good from the implementation
   standpoint.

   RS: Where does it belong?

   <AmeliaBR> s/due to native roles/due to native roles, except
   for role=none/presentation/

   CS: I don't think it needs to be in the ARIA spec.

   RS: But what Joseph was saying is that it's in different places
   in the ARIA spec.

   JS: We have a section in the Core AAM which points to the ARIA
   spec.
   ... And what it points to in the spec is huge and not
   especially clear.

   ABR: So the section in the Core area that needs to be cleaned
   up are the rules when an author-supplied role of
   presentation/none will be ignored.

   <clown>
   [22]https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#e
   xclude_elements2

     [22]
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#exclude_elements2

   CS: Maybe we need a sentence which says what attributes will
   cause that role to be ignored.

   ABR: It's there, but lost in the other text.

   RS: Other than aria-labelledby....

   (Group discusses which attributes are relevant)

   RS: I'll put it in presentation.

   JS: Put a subsection in presentation with all these little
   nuances.

   RS: I'm not sure how to put the subsection, but I'll give it
   some thought.

   JS: Looking at the current exclusion rules, aria-hidden is a
   SHOULD NOT; not a MUST NOT.

   ABR: Rich, did you have any more questions about the changes
   you'll make to the ARIA spec?

   RS: I don't.

   ABR: Why don't we shift focus to the Core AAM spec then?
   ... We have things which are currently described as SHOULD NOT
   rather than providing very clear rules.
   ... Part of the problem is that these are some of the things
   which should be excluded, except for other things.
   ... Is that why it was done as SHOULD NOT?

   JS: I know the history.
   ... It used to say, you must rely on the CSS only.
   ... That gradually weakened over time.
   ... Firefox insisted on keeping aria-hidden things in the tree
   for 1.0.

   JD: They've since pruned the tree.

   CS: Why don't we change it to a MUST NOT and see what they say.
   ... We should explicitly ask them for their feedback.

   JS: I'll ask Alex.

   <clown>
   [23]https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#a
   riaHiddenTrue

     [23]
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaHiddenTrue

   JS: And also point this out.
   ... If you look at the above, every last one indicates should
   not be exposed unless it fires an event or is focusable.

   CS: That's true.
   ... MUST NOT be in the tree unless the above condition is met.
   In which case is MUST be in the tree.
   ... Let's get rid of all the SHOULD's

   ABR: aria-hidden overrides global attributes where
   presentational role does not.

   CS: Which is actually a big difference.

   JS: I made a note of that.
   ... Can we wrap this up?

   CS: Do we want to make the change, or talk to the Firefox
   developers first?

   JS: Give me an action.
   ... Actually, I have an action.

   action-1681

   <trackbot> action-1681 -- Joseph Scheuhammer to Propose new
   wording, as an editorial change only to clarify the inclusion
   rules in section 5.1.2 -- due 2015-09-15 -- OPEN

   <trackbot> [24]http://www.w3.org/WAI/ARIA/track/actions/1681

     [24] http://www.w3.org/WAI/ARIA/track/actions/1681

   JS: I think the rules are all there, but ambiguous. So it's
   mostly editorial.
   ... The change from a SHOULD to a MUST is the exception.
   ... I'm going to push the due date out to two weeks from today.
   ... Will your text be done in two weeks, Rich?

   RS: I can try.

   JS: I'm putting a note in my action that it depends on yours,
   Rich.

Summary of Action Items

   [NEW] ACTION: Rich to separater out text from
   role="presentation/none" so that a single location may be
   referenced in Core-AAM. [recorded in
   [25]http://www.w3.org/2016/03/29-aapi-minutes.html#action01]

     [25] http://www.w3.org/2016/03/29-aapi-minutes.html#action01

Summary of Resolutions

   [End of minutes]
Received on Tuesday, 29 March 2016 20:12:00 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:21 UTC