See also: IRC log
<scribe> scribe: MichielBijl
MK: We’re done with button, will close it
Related issue: https://github.com/w3c/aria-practices/issues/316
MK: Will add reasoning to the
commit
... topic Modal Dialog
Any accessibility issue?
MB: No accessibility issues, just aesthetics.
https://github.com/w3c/aria-practices/issues/321
MK: terracoda is working on the inputs overflowing, after that you can work on design
MB: Understood
MK: Would be good to have this done before the next heartbeat
MB: I’ll be able to do the design and the reviews this week, but see more people on the list
Related issue: https://github.com/w3c/aria-practices/issues/325
JN: Haven’t looked at the code, but it’s in the states and properties table
MK: Not sure if the spec has a default value for it (aira-dialog)
JN: Default is false
MK: Isn’t that odd?
JN: No, if people made dialogs that they didn’t want to be modal that would change if it was
MK: Jemma made a comment
About using DL / DT | DD
Didn’t we close that discussion?
We went away from it and came back to it, because DL is a much better fallback than just having a bunch of divs.
Semantically it matches up fine
So, I’m unclear what you mean by your comment
JK: I’m fine with the DL
My first reaction was that it was for data table
http://w3c.github.io/html/grouping-content.html#the-dl-element
MB: DL stands for description list.
MK: Okay, so that fits even better now
Does anyone see any open issues here?
JK: What is the advantage of the DL over a bunch of divs?
MK: Has a bunch of advantages, like SRs will announce number of items in the list and you can jump from question to question.
JK: Makes sense
MK: Did you read it MB?
MB: I glanced over it, looks good, I’ll look at the undocumented feature
https://github.com/w3c/aria-practices/issues/291
MB: I fixed the issue James mentioned
Think Paul’s comment is interesting, but for next release
MK: Filed new issue, for 1.2
https://github.com/w3c/aria-practices/issues/327
MK: Closing issue 291
https://github.com/w3c/aria-practices/issues/324
MK: Thank you very much Jon
JG: Do we care about mouse behaviour?
MK: Of course!
JG: When you click on a menu they stay open
JN: That’s not default on Windows
MK: Why is it different for spacebar?
JN: Oh, on Windows spacebar doesn’t even activate them
MK: Oh, great!
Seems user-unfriendly.
MK: Could make spacebar optional
JN: That’s a good idea
MK: Will raise an issue
MB: Jon would you be okay with me re-designing it?
JG: Go ahead!
JK: What do you mean with make it prettier?
MB: Change colours, was thinking of something like the default macOS menu bar
JK: Also make it responsive?
MB: Not necessarily, would have to look at the code, perhaps for a later version.
https://github.com/w3c/aria-practices/issues/326
MK: Should menu buttons have aria-expanded on it
(suggested by Paul J. Adam).
MK: Personally I dislike the extra verbosity
There is an issue on iOS when using blur()
JN: I don’t see a big use for it, but lean towards it being okay
MK: I… we could make it something optional in the pattern
If we do that it should be consistent with the behaviour.
JN: I think it’s reasonable, it adds some code, but it’s not too hard
https://github.com/w3c/aria-practices/issues/277
JN: I need to log an issue against ARIA spec
MK: So Chrome is including the old content in the calculation?
sg/topic/topic/
MK: I see the logic of making it consistent
In most places owned and descendent are the same thing
JN: They don’t have test cases for this yet
MK: Leaves me up in the air
When I wrote these patterns
I want to get them consistent
JN: If you have aria-owns and rely on the children
You need aria-label of aria-labelledby to make it consistent
MK: You don’t it to be named by all the children
In Chrome you’ll need to use label/labelledby
Currently our examples don’t use aria-owns
I’m not terribly worried about it
JN: Why would you want aria-owns to be used as the accessible name calculation?
Is there a case where you want that?
https://github.com/w3c/aria-practices/issues/168
MK: Waiting on the table stuff
JN: Michiel has a simplification for the CSS
MB: Will push that this week
MK: Okay, will close the issue
https://github.com/w3c/aria-practices/issues/325
MK: Do you have any comments
Jemma?
... Can you review this this week MB?
MB: Yes
MK: James I like your comments
Your comment about tabindex=-1
That means you can set focus programatically, but its not in the tab order
Does that make scrolling harder?
MB: Shouldn’t make it harder, it’s a widget on top of the page, not in the page
MK: We should make sure our example is scrollable if it doesn’t fit in the viewport
JN: Both the dialog and the page scroll
MK: I’ll ask terracoda after the call
MB: When is the publication?
MK: Somewhere during next week
Not bound to a certain date
We want to get to the point where we have the design patterns done
When we get to ARIA 1.1
<jongund> bye
JK: Are we including modal dialog?
MK: Yes
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/Ggeat/great/ Succeeded: s/should// Succeeded: s/Menu/Should menu/ Succeeded: s/??/descendent/ Succeeded: s/Next up/topic/g Present: matt_king MichielBijl JaeunJemmaku ShirishaBalusani jongund JamesNurthen Found Scribe: MichielBijl Inferring ScribeNick: MichielBijl Got date from IRC log name: 20 Mar 2017 Guessing minutes URL: http://www.w3.org/2017/03/20-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]