See also: IRC log
<mck> it says the meeting code is invalid when I try to call on the phone
<sirib> no meeting to day?
<sirib> I can't access the link
<mck> yes, there is a meeting if we can have one
<sirib> can you send me webex link
<sirib> https://mit.webex.com/mit/j.php?MTID=m4b54b847795d432ef8a2ba82e488fea2
<sirib> getting meeting has ended or cancelled
<sirib> oops , sorry
<mck> ann, our meeting line has a problem
<jamesn> <MichaelC> which usually means a sysadmin unilaterally canceled it without telling me
<jamesn> <MichaelC> I´ll schedule a new one
<mck> OK, Michiel, I'll make a point of trying to annoy you further.
<AnnAbbott> Yes, meeting call in has a problem
mck, we’ll see who wins that battle :P
<mck> don't push me
<aaronlev> sorry forgot the pwd
<AnnAbbott> What is the WebEx password?
<scribe> scribe: MichielBijl
<aaronlev> erm what was that
<AnnAbbott> 666 444 732?
<AnnAbbott> I've never joined WebEx for this call before - sorry!
<AnnAbbott> I've always dialed in
<jamesn> oh dial in number?
<jamesn> 644 895 856
<AnnAbbott> Sorry - typo in my password above - it has always been 646 444 732
<AnnAbbott> when I try 644 895 856, it tells me password is incorrect
<mck> https://github.com/w3c/aria-practices/wiki/May-8%2C-2017-Meeting
<sirib> what is the password
Related links:
https://github.com/w3c/aria-practices/issues/325
https://github.com/w3c/aria-practices/issues/321
https://github.com/w3c/aria-practices/issues/334
MK: Some people aren’t satisfied with the current text
AA: I made a suggestion
MK: You suggested focus should always return to the element that invoked the dialog, unless that element doesn’t exist.
What about cases where that element isn’t the most logical place for it to go?
AA: ??
JN: isn’t maintaining a logical workflow the most important thing?
AA: if you got a design that’s so flaky, that focus is returned to the element that invoked it, and you can’t get to the element in the logical work flow, that’s a design flaw.
JN: We have a table where you enter new data, after you add one, we set focus to the row after the newly generated one, it’s the most logical place.
In that case it’s quite clear what the user wants to do.
MK: I agree with James
I think there’re some finer points to it
For example if you pressed the “add row” button three times it be useless to have to navigate back to it three times.
These are design decisions.
What we don’t want to do is to limit people that want to make a good design
AA: When a dialog closes return focus to the element that invoked it and have something for edge cases where that element no longer exists.
JN: I agree with that.
MK: I’m not totally fine with
that.
... Given the contents of this conversation, I have enough to
work on something that’s similar to what we have, but
shorter.
MK: First thing is this question
<mck> https://github.com/w3c/aria-practices/issues/223#issuecomment-298267313
SB: Matt did you get a chance to look at my comments?
MK: Do remember looking at them, don’t remember replying to them.
My question is about specific text.
*Ann reads the issues linked to above*
MK: This point is under the accessibility features.
On all the treeview example pages.
We have a custom focus and hover.
Link to code example: http://w3c.github.io/aria-practices/examples/treeview/treeview-1/treeview-1a.html
MK: What are the differences between the hover and focus state?
MB: On focus the treeitem gets a black border and a light grey background
When you hover the treeitem gets a slightly darker background
In addition to the custom focus state
You also get the default one
I suggest we remove the default one as it usually lacks sufficient indication depending on background.
MK: I’m okay with that
Should we have any guidance on it
JN: People are going them themselves, if not, we can ask them to.
MB: that does sound helpful (a section about focus indication)
*back to focus / hover styles*
MB: The hover and focus styles are applied through JS
Why aren’t these applied through CSS?
The last browser to not support :hover on <li> was IE 6
I’ll make a note of it in the issue
JN: We shouldn’t get stuck on this, perfection won’t get us to ship anything
MK: Agreed, but we should use correct techniques for things because it adds to the credibility of the document
JN: Agreed.
MK: Anything else someone wants to say about treeview before me move on?
<mck> https://github.com/w3c/aria-practices/issues/383
JN: The issue occurs in Firefox,
but not in Chrome
... You mention the thing in the thing so they’re cross
referenced
<AnnAbbott> Navigation Menu Button Example: http://w3c.github.io/aria-practices/examples/menu-button/menu-button-links.html
*James sneezes*
<sirib> lol
MK: When I try to reproduce it it’s not happening for me
AA: James you still have all those browsers still up?
All those you tested in?
JN: Can open them again
Do you want me to test the menu opening again in other browsers?
AA: Yeah, Chrome and IE11
JN: Moves to the typed character, but doesn’t close the menu
Works fine in IE as well
MK: What happens for me in FF 43
If I hit the letter A, it moves the focus to the first item with that letter, but it doesn’t close the menu for me.
JN: Doesn’t for me either
<sirib> can you please tell which issue we are looking at
383, I think
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/occurs/occurs in/ Succeeded: s/not/but not/ Present: matt_king MichielBijl AnnAbbott JaEunJemmaKu shirishaBalusani Found Scribe: MichielBijl Inferring ScribeNick: MichielBijl WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 08 May 2017 Guessing minutes URL: http://www.w3.org/2017/05/08-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]