- From: Joseph Scheuhammer <clown@alum.mit.edu>
- Date: Mon, 20 Oct 2014 14:39:51 -0400
- To: public-pfwg@w3.org
Link: https://www.w3.org/2014/10/20-aria-minutes.html
Plain text follows:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Protocols and Formats Working Group Teleconference
20 Oct 2014
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-pfwg/2014Oct/0118.html
See also: [3]IRC log
[3] http://www.w3.org/2014/10/20-aria-irc
Attendees
Present
Rich_Schwerdtfeger, +1.703.978.aaaa, Joanmarie_Diggs,
Michael_Cooper, Joseph_Scheuhammer, Cynthia_Shelly,
Jon_Gunderson, LJWatson
Regrets
Chair
Rich
Scribe
clown
Contents
* [4]Topics
1. [5]TPAC
2. [6]issue-679
3. [7]getComputedRole()
4. [8]Action 1335
5. [9]Action-1345
6. [10]Action 1346
* [11]Summary of Action Items
__________________________________________________________
<trackbot> Date: 20 October 2014
<richardschwerdtfeger> Meeting: W3C WAI-PF ARIA Caucus
<richardschwerdtfeger>
[12]http://lists.w3.org/Archives/Public/public-pfwg/2014Oct/011
8.html
[12] http://lists.w3.org/Archives/Public/public-pfwg/2014Oct/0118.html
<fesch> aaaa is Fred
<richardschwerdtfeger>
[13]http://lists.w3.org/Archives/Public/public-pfwg/2014Oct/011
8.html
[13] http://lists.w3.org/Archives/Public/public-pfwg/2014Oct/0118.html
<mattking> hi, Matt will join on phone in about 20 minutes
<scribe> scribenick: clown
TPAC
RS: Anything to discuss, Michael?
MC: Nothing in particular.
... crowded rooms. do our best with cross-group meetings.
CS: do we have a whitboard?
MC: I don't remember if there are any in the room.
CS: Maybe we can use really big paper.
RS: I'm not sure about our schedule for Thu afternoon.
<MichaelC> [14]PF Agenda at TPAC
[14] http://www.w3.org/WAI/PF/meetings/tp2014.html#agn
RS: I may have to step out and join a canvas meeting.
... We need some things agreed upon.
... I haven't heard back whether we are having the canvas
meeting on Thu.
MC: It looks like Thu afternoon is all cross-group meetings.
... <description of the meetings>
RS: <notes scheduling conflicts>
issue-679
issue-679?
<trackbot> issue-679 -- Glossary definition of value is
inaccurate -- raised
<trackbot> [15]https://www.w3.org/WAI/PF/Group/track/issues/679
[15] https://www.w3.org/WAI/PF/Group/track/issues/679
RS: Was brought up at an the AAPI call
... Has anyone fixed that?
JS: Not that I know of.
RS: any takers.
JG: I can try.
<scribe> ACTION: Jon to create a definition of "value" as per
issue-679 [recorded in
[16]http://www.w3.org/2014/10/20-aria-minutes.html#action01]
[16] http://www.w3.org/2014/10/20-aria-minutes.html#action01
<trackbot> Created ACTION-1520 - Create a definition of "value"
as per issue-679 [on Jon Gunderson - due 2014-10-27].
RS: Not needed for TPAC, Jon
... When due?
JG: How about two weeks?
[17]http://rawgit.com/w3c/aria/master/aria/aria.html#dfn-value
[17] http://rawgit.com/w3c/aria/master/aria/aria.html#dfn-value
JG: Three weeks, then.
RS: Dec 10th, Jon
getComputedRole()
RS: Lots of discussion.
... Numerous actions to ask browser vendors regarding if they
are willing to support this.
... The question is where do we tie it?
... Part of the AAPI, or tie it to an element.
<jcraig> issue-427?
<trackbot> issue-427 -- Need a way for application to find out
what role has been applied to or computed for an element --
open
<trackbot> [18]https://www.w3.org/WAI/PF/Group/track/issues/427
[18] https://www.w3.org/WAI/PF/Group/track/issues/427
RS: Where are you with this Cynthia?
CS: It's still an issue. No commitment yet, but no "no" either.
... It's considered an interesting idea, but not a priority.
JC: What does "part of an AAPI" mean?
RS: Alex was suggesting it is a call to the AAPI.
JC: But you would get back a part of the tree, but not a lot.
RS: But it wouldn't part of an Element.
JC: It would be in the DOM. You might get an accessible
element, and the role from that.
RS: I think that relying entirely on DOM content is going to be
problematic.
... Mostly because of the impact of CSS content.
... any other comments on this?
JC: Primary concern from implementors, not unsolvable, is the
fact that there is no way for a web author to initiate
accssibility code paths in browsers.
... So there is performance impact.
RS: it has to be purposeful.
JC: That's right. If we launch the accessibilty code at the
beginning it's one thing.
... If we spin it up and down everytime we need it give a
performance hit.
... If we put is outside the element interface, it would have
less impact.
RS: What about security issues?
JC: there are always security issues, but I don't know know of
anything specific..
RS: I don't see any way around this.
... We are going to have to go down this path.
... What are the next steps?
... Talk about this with browser vendors at TPAC?
... With the Web Apps group?
CS: How about an ad hoc meetin on Wed?
RS: Okay with me.
... With whom.
CS: The browser vendors can be recruited at the Web Apps
meeting.
JC: I prefer the regular meeting as I'll be attending remotely.
... I think I will attend more IndieUI more than CSS>
RS: How about the CSS interlock?
... CSS is a factor, and browser vendors will be at the CSS
meetings.
JC: We did request a role selector.
... But a CSS selector would be harder to make explicitly
performant than the JS interface.
MC: I don't think we have a specific time set for ?
CS: There is someone for MS for CSS. What day?
RS: On Thu.
JC: I think this is either a Web Apps discussion or Web Apps
with ARIA.
... We have a lot to discuss with CSS.
... And, the target is likely ARIA 2.0
RS: When is Web Apps meeting?
... no idea.
... Michael, can we have a meeting after the face to face with
Web Apps.
... Like we did with digitial pubs group — a phone meeing.
MC: Yes, we could do that.
RS: I think we do this afterwards.
CS: I think we should consider Wed.
JS: It's possible I could make it.
CS: It wouldn't have to be the whole day. Just, say, an hour.
... I think there is a wiki for pre-planning.
RS: Can you set that up, Cynthia?
CS: I'm not in web apps.
RS: Michael?
MC: I can try. I'm not sure what their process is.
RS: Can Cynthia or Michael set this up?
CS: I can.
Action 1335
action-1335?
<trackbot> action-1335 -- Joanmarie Diggs to Propose edit for
issue-493 to explicitly disallow strings matching "" or
"undefined" in this sentence: content authors must provide
values for required states and properties. -- due 2014-10-13 --
CLOSED
<trackbot>
[19]https://www.w3.org/WAI/PF/Group/track/actions/1335
[19] https://www.w3.org/WAI/PF/Group/track/actions/1335
JD: James Craig had already supplied the text.
... I did the work and closed the issue.
RS: You closed the issue too?
JD: Yes.
Various: Congrats to our newest edtior.
<jcraig> issue-545?
<trackbot> issue-545 -- Resolve live region and aria-relevant
conflict between spec an UAIG. -- open
<trackbot> [20]https://www.w3.org/WAI/PF/Group/track/issues/545
[20] https://www.w3.org/WAI/PF/Group/track/issues/545
Action-1345
action-1345?
<trackbot> action-1345 -- Joanmarie Diggs to Propose an edit
issue-545 resolving live region changes to dom vs a11y tree --
due 2014-09-30 -- OPEN
<trackbot>
[21]https://www.w3.org/WAI/PF/Group/track/actions/1345
[21] https://www.w3.org/WAI/PF/Group/track/actions/1345
JD: I updated that with proposed text.
<joanie> additions: Element nodes are added to the
accessibility tree within the live region.
<joanie> removals: Text or element nodes within the live region
are removed from the accessibility tree.
<joanie> text: Text is added to any descendant in the
accessibility tree of the live region.
JD: These are my proposals of the new text.
... What I just pasted in.
JC: The old text is:
<jcraig> Old text:
<jcraig> additions: Element nodes are added to the DOM within
the live region.
<jcraig> removals: Text or element nodes within the live region
are removed from the DOM.
<jcraig> text: Text is added to any DOM descendant nodes of the
live region.
<jcraig> all: Equivalent to the combination of all values,
"additions removals text".
<jcraig> additions text (default): Equivalent to the
combination of values, "additions text".
JC: Leave all and "addtions text" as is?
JD: I got rid of the DOM and specifically said the a11y tree.
<jcraig>
[22]http://www.w3.org/WAI/PF/aria/complete#aria-relevant
[22] http://www.w3.org/WAI/PF/aria/complete#aria-relevant
RS: Url to the table?
JC: This is just the values in the characteristics table.
JD: I haven't made the changes because I have questions.
JC: Should we say the "platform accessibility tree"?
... We have both the rendering engine of the a11y tree, and
also what is exposed through the API.
... I'm wondering if there any difference.
RS: What don't we call it the a11y tree exposed to the AT.
JC: I don't think any ATs reach into the browsers internal a11y
tree.
RS: FF has an internal tree.
JC: I think what Joanie has is okay … let me re-read.
RS: This is defined in the mapping guide.
... Right Joanie?
... You could say "the platform AAPI tree".
JC: A possible problem. Thinking out loud:
... The code that makes this work is in the rendering engine in
a place that it's not clear how it's exposed on the platform.
... What we call a node here may or may not be a node on the
platform.
... I think though that this mighe be implementation details.
... But, we won't know until people report bugs.
RS: I was trying to give a vocabulary that is consistent with
our documents.
... How about:
<richardschwerdtfeger> the platform accessibility API tree
mapping
JC: Is "platform" needed?
RS: I don't think so, but there is no generic API today.
JC: All of the browsers have their own internal a11y tree.
JD: Why is "mapping" desired here?
<Zakim> jcraig, you wanted to discuss the word "add" in "text:
Text is added to any DOM descendant nodes of the live region."
JC: I think what Joanie is saying is fine.
... For the text defnintion, "when text is added"
... It's difficult, we could do a string comparison and not
fire it if there is no difference.
... we don't have text additions and text removals.
MK: You couldn't have a status with one element, and you're
adding text to it.
... "Text or element nodes within the live region". Does that
mean any descendant?
JC: Any descendant, no matter now deep.
<jcraig> Element nodes are added to the accessibility tree
within the live region.
RS: Also CSS could be adding text here, and there may be
nothing in the DOM>
JD: My problem was the DOM vs. the a11y tree.
... I have all sorts of questions about aria-relevant as well.
MK: Does aria-relevant default to all?
JC: It defaults to "addtions text".
<Zakim> jcraig, you wanted to discuss "text alternatives" not
just "text"
JC: The other thing ARIA 1.0 didn't include text alternatives.
... So if you changed the alt text on an image, it wouldn't
speak because the text content didn't change.
... We could say text or text alternatives.
MK: The way WCAG is written, it sounds like alt text is text.
CS: I think text alternaitve is clearer.
RS: If we said rendered text or alternative text.
JC: We shouldn't say "rendered text" because someone might
conclude that references something off screen.
... Just use "text or alternative text'>
MK: If you say text content or text alternatives, that would
bring in the CSS content.
RS: Any objections?
JN: Does this include the case where someone changes the
aria-label?
JC: Yes.
JN: Should we add something in the text alternative
computation?
JC: We need another normative statement outside the
characteristics table regarding the text alternative
computation.
... A normative statement for UAs within the spec.
RS: Do you have enough to re-do this?
... Joanie?
<joanie> When text changes are denoted as relevant, user agents
must monitor any descendant node change that affects the text
alternative computation of the live region as if the accessible
name were determined from contents (nameFrom: contents). For
example, a text change would be triggered if the HTML alt
attribute of a contained image changed. However, no change
would be triggered if there was a text change to a node outside
the live region, even if that node wa[CUT]
JD: There is something about text alternative computation.
... It's above the characteristics table.
<jcraig> When text changes are denoted as relevant, user agents
MUST monitor any descendant node change that affects the text
alternative computation of the live region as if the accessible
name were determined from contents (nameFrom: contents). For
example, a text change would be triggered if the HTML alt
attribute of a contained image changed. However, no change
would be triggered if there was a text change to a node outside
the live region, even if that node was
<jcraig> referenced (via aria-labelledby) by an element
contained in the live region.
<fesch> what is agenda?
RS: It would be clearer if we said, "if text content or
computed name …."
... That would cover it, right?
JC: Right.
MK: Was that restriction on outside the region there for
performance regions?
RS: Probably.
JC: It's complicated enough just monitoring descendant nodes.
RS: If you are monitoring the name, it make senses to notify of
the change.
MK: It seems okay to me, but I don't write browsers.
CS: I can ask my dev to see how hard this is, and how
performant.
JC: We also put in the ARIA 2.0 list that there are so many
inconsistencies in live regions that it would help if there was
an accessibility announcement interface.
... "trigger this announcement with this text".
JN: I agree.
... My experience is that 90% of the usage of live regions is a
general text announcement system already.
JC: Does 'text content and text alternatives" work for you
James N?
JN: That's fine.
RS: Joanie, if you make those changes, instead of using nodes,
that would be better.
JD: Okay, I can do that.
<joanie> Indicates what user agent notifications assistive
technologies will receive when the accessibility tree within a
live region is modified. See related aria-atomic.
JD: But, I have a few more questions.
<joanie> old: Indicates what user agent change notifications
(additions, removals, etc.) assistive technologies will receive
within a live region. See related aria-atomic.
+1
<richardschwerdtfeger> +1
JC: Semantic nit pick.
<jcraig> Indicates what notificatoins the user agent will
trigger when the accessibility tree within a live region is
modified. See related aria-atomic.
JC: Some ATs may not care about all of theses notifications.
<richardschwerdtfeger> Indicates what notifications the user
agent will trigger when the accessibility tree within a live
region is modified. See related aria-atomic.
CS: I agree, in UIA, you have to subscribe to notifications.
<richardschwerdtfeger> +1
+1
<jcraig> +1
<LJWatson> +1
<jongund> +1
<fesch> +1
<mattking> +1
<joanie> Both accessibility APIs and Document Object Model
Level 2 Events [DOM-Level-2-Events] provides events to allow
assistive technologies to determine changed areas of the
document.
JD: Is the above text even relevant?
JC/RS: No.
RS: And we are on DOM level three now.
JC: And this makes things more confusing re: DOM nodes vs. a11y
tree nodes.
RS: Let's remove it.
JD: I will update the action, and push the changes, then.
Action 1346
action-1346?
<trackbot> action-1346 -- Matthew King to Propose edit to
dialog role to clarify issue that leads to bad implementation
-- due 2014-10-06 -- OPEN
<trackbot>
[23]https://www.w3.org/WAI/PF/Group/track/actions/1346
[23] https://www.w3.org/WAI/PF/Group/track/actions/1346
MK: the text is in the action, in a note.
<richardschwerdtfeger>
[24]https://www.w3.org/WAI/PF/Group/track/actions/1346
[24] https://www.w3.org/WAI/PF/Group/track/actions/1346
<richardschwerdtfeger> dialog (role)
<richardschwerdtfeger> A dialog is an application window that
is designed to interrupt the current processing of an
application in order to prompt the user to enter information or
require a response. See related alertdialog.
<richardschwerdtfeger> Authors SHOULD provide a dialog label.
Labels may be provided with the aria-label or aria-labelledby
attribute if other mechanisms are not available. Authors SHOULD
ensure each active dialog has a focused descendant element that
has keyboard focus.
<richardschwerdtfeger> dialog (role)
<richardschwerdtfeger> A dialog is a child window of the
primary window of a web application. For HTML pages, the
primary application window is the entire web document, i.e.,
the body element.
<richardschwerdtfeger> Dialogs are most often used to prompt
the user to enter or respond to information. A dialog that is
designed to interrupt workflow is usually modal (see related
alertdialog).
<richardschwerdtfeger> Authors SHOULD provide a dialog label,
which can be done with the aria-label or aria-labelledby
attribute.
<richardschwerdtfeger> Authors SHOULD ensure that each active
dialog has a focusable descendant element with focus and that
focus is trapped inside the dialog. If the dialog is modeless,
authors SHOULD ensure there is a keyboard mechanism for moving
focus between the modeless dialog and other application
windows.
<richardschwerdtfeger> Note: In the description of this role,
the term "application" does not refer to the application role,
which specifies specific assistive technology behaviors.
<mattking> A dialog is a child window of the primary window of
a web application. For HTML pages, the primary application
window is the entire web document, i.e.,
<mattking> the body element.
<mattking> Dialogs are most often used to prompt the user to
enter or respond to information. A dialog that is designed to
interrupt workflow is usually modal (see
<mattking> related alertdialog).
<mattking> Authors SHOULD provide a dialog label, which can be
done with the aria-label or aria-labelledby attribute.
<mattking> Authors SHOULD ensure that each active dialog has a
focusable descendant element with focus and that focus is
trapped inside the dialog. If the dialog
<mattking> is modeless, authors SHOULD ensure there is a
keyboard mechanism for moving focus between the modeless dialog
and other application windows.
<mattking> Note: In the description of this role, the term
"application" does not refer to the application role, which
specifies specific assistive technology behaviors.
MK: The difference is making the definition more broad, that it
is a child window.
JS: Nit: sometimes dialogs are spawned by other dialogs, so not
always a child of the main window.
FE: But it still is a descendant.
MK: How about change "child" to "descendant"?
... Doesn't always interrupt. It may be amodal.
RS: It puts the window at the top level, and covers the main
content.
MK: This text is removing the restriction that it always
interrupts, or must be treated as an application.
... Author SHOULD is to provide something focusablle.
<richardschwerdtfeger> The graphical control element dialog box
(or dialogue box) is a small window that communicates
information to the user and prompt them for a response.
MK: What about tool panes (thesaurus, style) in a word
processer that are amodal.
... They can be closed or invoked or ignored while open.
Definition of window role: A browser or application window.
[25]http://rawgit.com/w3c/aria/master/aria/aria.html#window
[25] http://rawgit.com/w3c/aria/master/aria/aria.html#window
[26]http://rawgit.com/w3c/aria/master/aria/aria.html#window
[26] http://rawgit.com/w3c/aria/master/aria/aria.html#window
RS: We are out of time.
... Let's pick this up on the next go around.
<jcraig> (bye everyone)
MK: I will make the suggested changes, and add in a new note.
Summary of Action Items
[NEW] ACTION: Jon to create a definition of "value" as per
issue-679 [recorded in
[27]http://www.w3.org/2014/10/20-aria-minutes.html#action01]
[27] http://www.w3.org/2014/10/20-aria-minutes.html#action01
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [28]scribe.perl version
1.138 ([29]CVS log)
$Date: 2014-10-20 18:36:09 $
__________________________________________________________
[28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[29] http://dev.w3.org/cvsweb/2002/scribe/
--
;;;;joseph.
'Array(16).join("wat" - 1) + " Batman!"'
- G. Bernhardt -
Received on Monday, 20 October 2014 18:40:26 UTC