- 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>
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:02 UTC