Scribe, jongund
<MarkMccarthy> scribe: jongund
JN: meeting next week
... I cannot meet on July 2nd
<pkra> +1
JG: Just cancel it
https://github.com/w3c/aria/issues/1290
JN: Issue related to nested modals, can we do this in 1.3?
JC: Yes definitely not 1.2, maybe
1.3
... Webkit has an implementation that could be standardized
JN: If we can find an easy solution that would be awsome
https://github.com/w3c/aria/issues/1289
JN: Putting aria-haspop on a link
CM: This is a 1.2 issue
JN: Let's try to talk about it later today or next week
CM: It doesn't included in the working draft
JN: You can use rawgit on stable has the current what's in and what's out, use rawgit
https://github.com/w3c/aria/issues/1288
JN: From Wilco
CM: It's in 1.2
JN: I have a feeling this is more than just label, but if it is a different attribute it could cause the same issue
CM: I guess, but it was about label
JN: Is this only about label? It might be just an example of their concern
CM: Put in a comment that we should close it
JC: Conflict on presentational roles
JN: On presentational elements we
do not allow labelling
... Authors must not or should not....
... If you put a global on a presentational role, it is an
authoring error
... Don't do it or 1.3?
SO 1.3
PK: I have some changes
JN: You have had some approvals
JC: Removing ranges of characters
PK: It creates a link to the commons
JC: I will approve them
JN: I am going to merge it soon
JN: Open UI community group
working with the ARIA group
... I invited Greg to the deep dive next week, to see how we
can help each other
CM: Has anyone looked at it?
<MarkMccarthy> Note: URL is https://open-ui.org - there is an extra quotation mark in the above clickable link
CM: It is an awesomeproposal, but it is a ton of work
<jamesn> https://github.com/w3c/aria-practices/issues/1422
JN: I think alot of work would be
with practices, but we can talk about that next week
... He was on the edge team now with salesforce
<jamesn> https://github.com/w3c/aria/issues/1277
<jamesn> https://github.com/w3c/aria/issues/1277
CM: I sent e-mail about this, please review
<jamesn> https://github.com/w3c/aria/pull/1278
CM: Don't look at the issue, go
to PR, the issue is out of date
... Just look at the 3 small changes in the code
JN: I need some reviewers
... We are making progress on 1.2 issues
<Jemma> https://www.irccloud.com/pastebin/8BalNiJZ/
https://github.com/w3c/aria/issues/1275
JN: The reviewers are done
... I just merged
<jamesn> https://github.com/w3c/aria/pull/1224
JN: We have approvals form carolyn and matt
JC: I can't take myself out of the list, but I am not doing any more review
discussing alex's comments
JN: Aaron are you ok with this?
<jcraig> Fine with group resolution, but requested comments from Alex and Aaron "@cookiecrook requested review from asurkov and [alev] and removed request for cookiecrook on May 8"
AL: I had to many tabs open, let me look it
JN: Peter are you ok with this?
PK: I think it is OK
AL: I marked approved
JN: Anymore discussion?
JC: Merge
JN: I will merge after the
meeting
... I dismissed your review James
... Looks like it will get merged
... We have one issue left
JG: Isn't it related to the link button discussion earlier in the call
JN: This is from a colleagueof mine, if a link opens up in a dialog
SB: It should be a button, screen reader have terrible support for has-popupon a link
JN: AT make it a menu button
HS: I am with Sina with this, I
won't fight keeping off, but I don't think it is something that
is needed
... Nobody really knows why we need has-popup=dialog is
needed
JC: I don't know of any native scenarios
SO: We had prior agreement that it should not be on links
JC: There are still instances,
where people will use links to open windows
... People will use Javascript to open windows instead of an
HTML window, so I don't have any theoretical opposition on
link
JN: It is like a big tooltip with
navigation
... It changes focus, but not visual context
SB: How does your focus go back
JN: It is modal
SB: From a screen reader perspective is it modal?
JN: Yes
SB: It must have a close button
JN: Or an escape key
JC: I think there are some use cases for has-popup on a link, there is an example using history and the back button
SB: When it is done wrong it is a nightmare
JC: When it is wrong people want us to remove aria-hidden
JN: I need to go for a minute
SO: My other question, do we need
all these different values?
... If it is important to have it on a link, it is weird that
all thse values are allowed on a link
CM: good point
values grid, dialog, list ...
JC: We could have some guidance
<Scott_O> https://github.com/w3c/aria/issues/1024
MC: There is a mixed restriction on checked
<MarkMccarthy> github: https://github.com/w3c/aria/issues/1289
JN: There are other places aria-haspopup that these values may not make sense
SO: This is a loaded thing and
all the values make sense, are these really needed?
... A screen reader would know, but visually they all look the
same
JC: The impact, links can have
stylistic differences, like on wikipedia
... The potential oddity to the user, when there is something
that does not make sens
... The user may want to ask someone what is going on when it
does not make sens
... I am not a fan of limiting vocabulary, since we often find
use cases
SB: When you use speech syllables have a cost
JC: It is only a problem when it is weird
JN: The change will cause
validation errors, since it global now
... We need to make changes in the AAM
SB: I need a win, I get JC
<pkra> gotta drop off early - bye everyone.
JC: Wikipedia doesn't use haspop, it was just an example of styling links differently
SB: I am worried developers wee this and think they should use it
MC: We can add a don't to this
SB: I won't fight it, but I think this not a good practice
SO: I am also concerned about author abuse
JN: I see two ways: add it back
to links, or links do not need to use it
... If you don't need it explain why they don't need it
JC: I would say, what styling did you use to indicate behavior, so if the sighted user doesn't know there is a dialog, the screen reader is in the same position
SB: But sighted users don't get length of lists
JC: But they can grok it
SO: If it is the difference in the controls visual styling to indicate the popup, then it should be used...
JC: It is a judgement call, it designers did styling to convey the behavior, then it should be used
SO: That is the start of a
note
... The necessity of this attribute is not always needed, and
we need to communicate that part of the decision is based on
visual information
JC: Most menu buttons have a cheveron to indicate visually a popup
SO: Then there is a decision tree on what to convey
JN: This sounds more like authoring practices, or both
SO: The note in the spec does not have to be long
JN: Do we have agreement to put this back on link?
<Jemma> +1
<jcraig> +1
+1
CM: Or don't care
<Jemma> I agree
SO: we had agreed we wouldn't remove global attributes if there were valid use cases we didn't want to invalidate. I still think it's silly on a link, but ok
JC: We need to add an issue in APG to discuss this issue
JN: aria-haspopup should only be used when there is a visual indicator
JC: When there is a visual indicator...
Several people will review
<jcraig> I added this to the issue:
<jcraig> aria-haspopup is most relevant to use when there is a visual indicator in the element that triggers the popup. For example, most menu buttons are styled with a downward pointing triangle or chevron, which indicates to sighted users that the button will display a menu when clicked. If some functional difference is relevant to display to a sighted user by means of a different visual style, that functional difference is usually relevant to convey to
<jcraig> users of assistive technology.
<jcraig> If there is no visual indication that a element will trigger a popup, authors are advised to consider whether use of aria-haspopup is necessary, and avoid using it when it's not.
This is scribe.perl Revision of Date 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/scribe: jonbund// Succeeded: s/awsome /awesome/ Succeeded: s/the alex's/alex's/ Succeeded: s/collegue /colleague/ Succeeded: s/linl/link/ Succeeded: s/don;t/don't/ Succeeded: s/theoricial/theoretical/ Succeeded: s/musy/must/ Succeeded: s/It doesn't changes focus/It changes focus/ Succeeded: s/haspopup /has-popup/ Succeeded: s/SIO/SO/ Succeeded: s/won;t/won't/ Succeeded: s/don;t/don't/ Succeeded: s/ls// Succeeded: s/ SO: We don't think we want to have validation errors, I think it is silly/SO: we had agreed we wouldn't remove global attributes if there were valid use cases we didn't want to invalidate. I still think it's silly on a link, but ok/ Present: StefanS jamesn pkra MichaelC Scott_O MarkMccarthy jongund CurtBellew BGaraventa harris carmacleod Jemma Sina Regrets: GretaKrafsig JoanmarieDiggs MattKing Found Scribe: jongund Inferring ScribeNick: jongund WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]