See also: IRC log
<scribe> scribe: MichielBijl
https://github.com/w3c/aria-practices/issues/325
If a dialog is limited to interactions that either provide additional information or continue processing, it might set focus to the element deemed to be most frequently desired, such as a OK or Continue button.
MB: Why is it “it might set focus”?
MK: Design decision
We’re not using phrasing like should
MB: Can it still be “focus can be set” or something?
MK: Sure
MB: In this paragraph
When a dialog closes, focus typically returns to the element that had focus before the dialog was invoked. This is often the control that opened the dialog. In circumstances where that element no longer exists, focus is set on an element that supports a logical work flow.
Why is it typically returns and not simply “returns”?
MK: Because it might not exist anymore
Also if you open it from a menu, that menu item might not be visible anymore.
<jemma> +q
MB: The last sentence would sort of catch situations where you wouldn’t return focus?
MK: Not in all cases
Trying to think of cases where it wouldn’t
AA: The meaning of the sentence wouldn’t drastically change whether it would include typically or not?
MK: It’s different enough
<jamesn> Example - button to add rows to a table. Dialog pops up - how many rows do you want to add? Answer 5 and press ok. Now my focus should go to the new row, not the button.
MK: Also added guidance on aria-hidden:
Optionally, if content outside a dialog is completely inert and visually obscured to an extent that is intentionally unreadable, each element containing a portion of the inert layer has aria-hidden set to true. In this circumstance, the dialog container element cannot be a descendant of an element that has aria-hidden set to true. However, if content outside
a modal dialog is visually discernable, aria-hidden is not present.
JK: What is the use case?
JN: Use case here is that you don’t want the stuff to be visible
We should motivate advise people to use aria-modal
MK: I tried to write it that way
If that doesn’t come across, than we need to change it.
Tried to write an anti pattern without it looking like an anti pattern
aria-modal doesn’t put any requirements on AT
JN: Really?
MK: As far as I’m aware, yes.
JN: It works in iOS 10
MK: That’s iOS, not web
JN: I mean, I tested it on web on
iOS
... Often you put a background up to slightly obfuscate the
inactive part of the page.
MK: It starts making it harder to judge when to use modal
<jemma> https://www.w3.org/TR/wai-aria-1.1/#aria-modal
MB: If you use a modal dialog you can’t interact with the rest of the page, keyboard, at or visually, shouldn’t matter
B?: Yeah
MK: Okay, what if you should be able to interact with he rest of the page?
B?: Well, then users could wander off to parts not related to the modal. That doesn’t make sense.
MK: Trying to think of use cases
If people who can’t see are able to read outside of the modal, and that’s useful to them
MB: In that case, you should read the content before you open the modal dialog surely?
JN: Most dialogs I see cover the entire page anyway
In most cases anyway
Don’t think we should worry too much
MK: Bryan was arguing that aria-modal is pretty useful
Since this is the 1.1 guide, should we say aria-hidden not to be used?
B?: Would never say never.
JN: add a note saying that in ARIA 1.1 we have aria-modal which replaces the need to use aria-hidden in which was needed in aria 1.0 for the same functionality.
B?: That makes sense
JN: I can take the task to do that
MK: If you want to make a note in the issue that’s good enough
JN: Will do that
<sirib> Can you please give me link to example?
MK: Wondering how AT vendors are going to interpret it
Our wording is important
We’ll save that conversation for alter
AA: Thought AT venders developed based on the spec, not the APG
<jemma> here is the example, siri. http://w3c.github.io/aria-practices/examples/dialog-modal/dialog.html#
MK: Spec doesn’t tell vendors what to do
AA: And the APG does?
MK: No, but it gives them practical advise on how users will interact with it
https://github.com/w3c/aria-practices/issues/321
example: http://w3c.github.io/aria-practices/examples/dialog-modal/dialog.html
MK: All the changes that were made last week were related to Bryan’s feedback
And I’ve tested in all the browsers I have available to me
Jemma you were talking about the add delivery address dialog
JK: The styling is confusing, because the dialog that opens when you activate “accepting an alternative form” it has the exact same size as the previous one.
MK: Is it confusing that you open layers of dialogs?
JN: Yes, it’s the exact same size as the previous one and is the exact same thing
MK: Michiel, you were talking about doing a new design, is this something you can solve with CSS?
MB: Yes, I’ll have a look, although I’m not sure how to handle layered dialogs
MK: Good
JN: I’m now in a situation where I can’t close the “Verification Result” dialog
But don’t ask me to reproduce it
There’s also an issue on mobile
Should I put an comment in for that
The background scrolls
MK: Does it happen the same way in all the dialogs?
JN: yes.
MK: Let’s first do the CSS
Michiel, when you make changes, can you make a PR so I can review?
MB: Sure.
MK: James, which mobile device were you using
SB: The special instructions
Can you add aria-describedby to the special instructions so that the user can hear that too?
MK: Yeah I can do that
JN: I tested on iOS
AA: What is #334?
MK: That’s Michiel working on a new design
CSS
MK: Didn’t want to do another publication before all these design pattern reviews are done.
Thought it’d be more valuable if the group felt the document was in a more stable form
AA: You mean done?
MK: yeah, although that’s sort of relative in this world ;)
Not feeling super ready to get through with this
Let’s see how far we get in the next two weeks
I don’t have the bandwidth at the moment
before the weekend of April 7th
JN: I’ll be able to put a fair amount of work into the APG next week.
MK: We’ll assess on April
10th.
... Jon you have some open PRs
JG: Did some work this morning
MK: We can talk about the reviews after the meeting
JG: That would be good
MK: Michiel are you able to get your issues done?
MB: Yes
MK: Including the syntax one?
MB: O right, yes
MK: Anybody else that has some cycles to take up something?
AA: Can you let us know explicitly if you want us to review something?
MK: Would it be helpful if you completed your review and you provided your comments
That I’d take you off the owners list?
AA: No that’s fine, just when want us t look at something again
MK: Okay, I’ll be extra explicit
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/No ScribeNick specified. Guessing ScribeNick: MichielBijl// Succeeded: s/Inferring Scribes: MichielBijl// Succeeded: s/??/add a note saying that in ARIA 1.1 we have aria-modal which replaces the need to use aria-hidden in which was needed in aria 1.0 for the same functionality./ Succeeded: s/topic: question about modal dialog// Succeeded: s/asses/assess/ Present: MichielBijl JaEunJemmaKu AnnAbbott jamesn matt_king ShirishaBalusani jongund Found Scribe: MichielBijl Inferring ScribeNick: MichielBijl Got date from IRC log name: 27 Mar 2017 Guessing minutes URL: http://www.w3.org/2017/03/27-aria-apg-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]