See also: IRC log
<trackbot> Date: 17 November 2014
<MichaelC> agendum 7 = dialog role
Zakim: scribenick LJWatson
JS: Reminder that we should be
talking about mappings documentation.
... Guides are usually associated with non-normative documents,
whereas mappings are normative. We need to be careful to use
the right terminology/shorthand.
JD: Believe mappings in HTML AAM are incorrect.
JS: File bugs.
MC: Should we meet?
... Looks like three regrets. We should probably go ahead. Rich
will be back too.
MC: PF charter will be sent to AC
reps soon. Need to be sure the timelines it references are
accurate.
... How long do we need to be in working draft for example?
JS: Is testing included?
MC: Yes, we have to factor it in.
CS: Core is in decent shape, but HTML is out of date. Perhaps less than a year for core.
JS: There are a couple of new
things in the spec that will need to be dealt with.
... We need a round of going through 1.1 issues and
culling/postponing until 2.0
MK: Won't time nautrally
cull?
... If deadlines are missed for spec text/testing to be
done...
MC: Depends on how seriously we
take the deadlines.
... We won't answer this now, but it's good to be thinking
about it.
<clown> issue-681
<trackbot> issue-681 -- Consider adding definitions for "node" and "text node" to the common terms shared document. -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/681
JS: It uses the terms "node" and "text node", turns out their not defined in the glossary. Raised an issue and proposed definitions.
<clown> Basic type of Object in the DOM tree or Accessibility Tree. DOM nodes are further specified as Element or Text nodes, among other types. The nodes of an Accessibility Tree are Accessible Objects.
<clown> Type of DOM Node that represents the textual content of an Attribute or an Element. A Text node has no child nodes.
JS: If no objections, I propose adding these definitions to the glossary.
JD: Is it relevant that all platforms have different accessible nodes in terms of the hierarchy?
JS: We don't know.
CS: Don't think it matters for the definitions.
JS: Both have trees and trees have nodes.
JD: I'm good with that.
RESOLUTION: TF agrees the definitions of node and text node, and their addition to the glossary.
<clown> ACTION: Joseph to add the definitions of "node" and "text node" as given in issue-681 to the glossary (common terms doc). [recorded in http://www.w3.org/2014/11/17-aria-minutes.html#action01]
<trackbot> Created ACTION-1534 - Add the definitions of "node" and "text node" as given in issue-681 to the glossary (common terms doc). [on Joseph Scheuhammer - due 2014-11-24].
MC: Last week we agreed to
publish 1.1, acc name and core on 11th December.
... Anything blocking?
JS: Willdo what's needed to get it ready.
MC: We need group approval, but we can do that the following week.
JC: Last of 11 should be done.
<MichaelC> aria-current discussion last week
MK: I have an incomplete action, apologies. Will get it done.
<MichaelC> getcomputedrole discussion from last week
JC: Filed an HTML bug.
<jcraig> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27294
JC: Other issues?
MC: Actions for Dominic, Cynthia and Joseph.
<MichaelC> close action-1464
<trackbot> Closed action-1464.
JC: Can close Dominic's.
MC: Will leave the others.
<jcraig> Cc'ed Dominic (M) on the HTML bug.
JS: Returning to aria-current... in the core mapping there is a table for events. Is anything wanted by any AT for aria-current in terms of a state change event?
JC: Depends on how the platforms want to implement this.
MK: For 1.1 the issue might be that we should make it a "should" or a "may". Possible we'll get two implementations, but that would be surprising.
JC: Yes, we should make it a "may" until then.
MC: In principle we should test anything that is "should", "must" or may", but in practice there is flexibility.
JD: Shouldn't we change it only if it can't be done?
CS: Would rather be more agreesive.
JC: Don't agree in a spec.
JS: It's an AT question I
think.
... If they don't need an event, it's a moot point.
JC: That's why we should wait to find out if that's the case before we make it nescessary.
JS: If it does into the events mapping table the assumption is that it's a "must".
CS: I'd put it in the table with an editorial note.
JC: There's nothing to put in the table because there are no platform events for this yet.
JS: ATK has the property change event.
CS: UIA does too.
JC: It's okay to state UAs SHOULD fire a generic attr change event. It's NOT ok to require an aria-current specific event.
CS: Right, plus a note.
<clown> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#mapping_events_state-change
CS: The events table was intentionally limited in 1.0. There is a lot of stuff that could go in, that isn't.
<clown> 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> https://www.w3.org/WAI/PF/Group/track/actions/1346
<mattking> https://www.w3.org/WAI/PF/Group/track/actions/1346
<mattking> dialog (role)
<mattking> A dialog is a descendant window of the primary window of a web application. For HTML pages, the primary application window is the entire web document,
<mattking> i.e., 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 a dialog is
<mattking> modeless, authors SHOULD ensure there is a keyboard mechanism for moving focus between the modeless dialog and other windows within the web application
<mattking> that contains it.
<mattking> Note: In the description of this role, the term "web application" does not refer to the application role, which specifies specific assistive technology
<mattking> behaviors.
<mattking> --------------------------------------------------
<mattking> In addition, add the following note to the window role:
<mattking> Note: In the description of this role, the term "application" does not refer to the application role, which specifies specific assistive technology behaviors.
<mattking> --------------------------------------------------
MC: Does this have dependencies on inert etc.?
<jcraig> what does modeless mean?
MK: We have "modal", "non-modal" and "modeless".
JC: What is "modeless"?
... Would prefer we not use that term. "Modal" and "Non-modal"
are well known.
MK: Yes, it means "non-modal", so we should change it.
JN: What about "not modal"?
JC: Would say a dialoge is "not modal", but not that is a "not modal dialogue". (should be "non-modal")
JS: Wikipedia makes a distinction between modal and modeless.
MC: Would argue that modeless is not the opposite of modal...
JC: Have concern about the text.
<jcraig> authors should ensure "that focus is trapped inside the dialog."
JC: It's tricky for browsers to implement.
MK: There are browser keys if you want to get away from that bit of the application.
JC: You're assuming users know all their browser hotkeys?
MK: No, just basic keys.
JC: Think non-modal dialogues should only impact the page, not the browser.
CN: Agreed.
+1
MK: As a user I find it confusing if focus leaves a dialogue and strays into the browser.
JN: We could write this in a way that doesn't encourage specific behaviour either way?
JC: Think I'd be ok with that.
JN: For a simple yes/no type dialogue it might be appropriate not to permit focus to return to the browser chrome.
CN: Don't think it should be restricted at all.
JN: You just remove one of the ways of returning to the browser, not all ways.
MK: This is how it works in other scenarios.
JC: Not always.
<bgaraventa1979> +q
BG: Would an overlay be considered a non-modal dialogue?
JC: If it was focusable, then potentially.
BG: If it contained more complex content?
MK: Could be done either way.
JC: If we added the word modal it would be more clear about trapping focus.
MK: Makes sense to trap focus on a non-modal also so you have a closed tab ring.
JC: If it's not modal why would you trap focs?
MK: The point of a dialogue is to
allow the user to focus on that particular task.
... Like the thesaurus sidebar in Word for example.
JC: If you accidentally left it,
you just shift tab to reverse direction.
... So how do you get in/out of it without closing it?
MK: In Word there is a hotkey.
JN: That isn't supportable cross-platform though.
MK: Could be a visible indicator.
JC: You mean a button or something?
MK: Yes, a "return to editor" or "close" button.
BG Sounds like it's getting too complicated.
JN: Agreed.
MK: So how do we crate the equivalent of something like the Word sidebar?
LW: Do we need to recreate that experience?
MK: I think we do.
<jamesn> +1 I think we need it too. I'm not sure I understand why role=dialog and aria-modal=false wouldn't achieve this
JC: Screen readers have different
mechanisms for navigating/moving focus.
... The concern is about mainstream keyboard users.
MK: Yes.
... But relying on shift tab to return to the top is hard work
for keyboard users.
<Zakim> jamesn, you wanted to say that i think we actually might need an overlay role in aria 2.0
<Zakim> jcraig, you wanted to propose change "that focus is trapped inside the dialog" to "SHOULD manages focus of the modal dialog." and to mention this is too vague to be an authoring
<Zakim> LJWatson, you wanted to say it would be bad UX to prevent focus returning to the browser chrome.
<jcraig> propose change "that focus is trapped inside the dialog" to "SHOULD manages focus of the modal dialog."
JC: requirement: "authors SHOULD ensure there is a keyboard mechanism for moving focus between a non-modal dialog and other windows within the web application"
<jcraig> this is too vague to be an authoring requirement: "authors SHOULD ensure there is a keyboard mechanism for moving focus between a non-modal dialog and other windows within the web application"
MK: Should manage?
JC: It's an author requirement.
MK: Within the modal dialogue?
JC: Depending on what type of
dialogue.
... Can we propose something like focus panel for the UI?
... Users have different expectations depending on platform...
key press, voice command, gesture etc.
MK: Window is meant to be
literal?
... Introducing the word panel would require a definition?
JC: Not that we'd use window
versus panel, just that we can't be specific.
... There is a section on managing focus, doesn't require
platform specifics. Could be a different key on different
platforms.
MK: So say "mechanism" instead of
"keyboard mechanism"?
... There's a point where it makes no sense to recommend a
dialogue, it may as well be a section of the page with a
designated purpose.
JC: But in a dialogue the AT can announce the change in context, entering and exiting.
MK: That's what ATs do with regions.
<jcraig> If it's a non-modal dialog, less distinction is needed between this and region.
MK: Do we need the non-modal attribute then?
JC: With speech you could say "move to next dialogue".
MK: Can do that with region.
JC: A dialogue is visually
distinct.
... Tool panels are like non-modal dialogues.
MK: Still wondering what the advantage of being so subtle in the spec is?
JC: The language right now is too restrictive—prescriptive, rather..
MK: Still don't understand the difference in AT behaviour for a non-modal.
JC: Semantics.
MK: We say the web application manages focus right?
JC: Maybe action should be take
the draft and massage it, then see if you're ok with the
changes?
... James N seems to see both sides of the coin, and has good
knowledge of varieties of dialogues...
JN: Yes, I can take a look at it. Give me two weeks.
<mattking> Authors SHOULD ensure that each active dialog has a focusable descendant element with focus and that the web application manages focus of the dialog.
<mattking> is trapped inside the dialog.
<mattking> Authors SHOULD ensure that an active dialog has a focusable descendant element with focus and that the web application manages focus of the dialog.
<jcraig> Authors SHOULD ensure that dialogs have at least one focusable descendant element. Authors SHOULD focus an element in the modal dialog when is is displayed, and authors SHOULD manage focus of modal dialogs.
<jcraig> Authors SHOULD ensure that modal and non-modal dialogs have at least one focusable descendant element. Authors SHOULD focus an element in the modal dialog when is is displayed, and authors SHOULD manage focus of modal dialogs.
<mattking> dialog (role)
<mattking> A dialog is a descendant 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.
<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 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 all dialogs (both modal and non-modal) have at least one focusable descendant element. Authors SHOULD focus an element in the modal dialog when is is displayed, and authors SHOULD manage focus of modal dialogs.
<mattking> Note: In the description of this role, the term "web application" does not refer to the application role, which specifies specific assistive technology behaviors.
MK: Goal was to get rid of the idea that a dialogue had to be treated differently to the application role.
JC: Can you clarify?
MK: Some screen readers were taking the "application" bit literally.
JC: Might be enough to reference the aria-modal attribute.
MK: We should link the word
"modal" to the attribute then?
... That's an editor thing right?
<jcraig> 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> https://www.w3.org/WAI/PF/Group/track/actions/1346
JC: Yes.
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/zakim, who is on the phone?/topic: Normative naming of mappings specifications/ Succeeded: s/out of dated/out of date/ Succeeded: s/impliment/implement/ Succeeded: s/It's ok to put an aria-current specific event in there I think./It's state a generic attr change event SHOULD be fired. It's NOT ok to require an aria-current specific event./ Succeeded: s/It's state a generic attr change event SHOULD be fired/It's okay to state UAs SHOULD fire a generic attr change event/ Succeeded: s/but not that is a "not modal dialogue"./but not that is a "not modal dialogue". (should be "non-modal")/ Succeeded: s/GB:/BG/ Succeeded: s/It's about all keyboard users./The concern is about mainstream keyboard users./ Succeeded: s/restrictive/restrictive—prescriptive, rather./ No ScribeNick specified. Guessing ScribeNick: LJWatson Inferring Scribes: LJWatson WARNING: Dash separator lines found. If you intended them to mark the start of a new topic, you need the -dashTopics option. For example: <Philippe> --- <Philippe> Review of Action Items Default Present: janina, Michael_Cooper, Joanmarie_Diggs, +1.703.978.aaaa, James_Nurthen, LJWatson, Fred_Esch, +49.322.110.8.aabb, Stefan_Schnabel, Joseph_Scheuhammer, Cynthia_Shelly, Matt_King, James_Craig, Bryan_Garaventa Present: Michael_Cooper Janina_Sajka Léonie_Watson James_Craig James_Nurthen Joseph_Scheuhammer Joanmarie_Diggs Bryan_Garaventa Fred_Esch Matt_King Cynthia_Shelley Agenda: http://lists.w3.org/Archives/Public/public-pfwg/2014Nov/0187.html Found Date: 17 Nov 2014 Guessing minutes URL: http://www.w3.org/2014/11/17-aria-minutes.html People with action items: joseph WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]