<scribe> scribe: MichielBijl

Current milestone review

https://github.com/w3c/aria-practices/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Jan+2017+Clean+Up%22+sort%3Aupdated-desc

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

modal dialog example

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

heartbeat publication

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.