<scribe> scribe: MarkMccarthy
<carmacleod> https://github.com/w3c/aria-practices/wiki/September-3,-2019-Meeting
Agenda link is above
<mck> Agenda link: https://github.com/w3c/aria-practices/wiki/September-3%2C-2019-Meeting
mck: [going through agenda for
the day]
... any additions? we have some room today
mck: we will have a meeting next
week Sept 10, but APG will not meet online on Sept 17. Only at
TPAC
... On Sept 24, there's not really a reason not to have a
meeting, just need to make sure agenda etc. is prepared before
going to Japan for TPAC
... if anyone has agenda topics for Sept 24, please submit
them
... hopefully we'll get some of Sarah's things covered by
then
jamesn: our meeting in Japan next
week will run from about 5p-2a Pacific Time
... Eastern time, 8p-5a
... I'll go through other things for ARIA WG on thursday, if
there's things people for sure want to dial in for and need
flexibility, let us know asap
<carmacleod> https://github.com/w3c/aria-practices/milestone/10
mck: there's a link to the draft
[above]
... we're about 50% done with the milestone!
... looking at the list, jamesn and I did some work on the
first thing on the list
... what's weird is that our changing the HTML structure broke
the keyboard listeners
jongund: what'd you change?
jamesn: i added a group around them
mck: basically nested in a list structure, they're grouped now
jongund: probably looking for specific child nodes, if it's deeper, maybe that's the issue. i can look
jamesn: that'd be good, I can't really see why it'd be an issue
jongund: okay, what branch?
mck: it's at the top of the PR list
<carmacleod> https://github.com/w3c/aria-practices/pull/1160
jamesn: I was confused why you wanted it merged into 1.1 master, mck
mck: we can talk about that
separately in an editors call, maybe
... master is now going to be 1.2 stuff except changelogs
etc.
jamesn: so this is a 1.2 issue then, right?
mck: yes; we have a 1.1 branch if we need, but i'm pretty sure we're done with that
jamesn: okay
mck: i want the editors draft to
reflect our recent work, but we can't merge everything into
master without messing up some things
... jongund, it's PR 1160
jongund: I got it
mck: thanks!
<Sarah_Higley> There's a number of firstElementChild selectors in the menubar JS, guessing that's the root cause: https://github.com/w3c/aria-practices/blob/master/examples/menubar/menubar-1/js/MenubarLinks.js#L58
<Sarah_Higley> (also used in menubar-2)
mck: carmacleod made a bunch of progress on the next item, hopefully i'll get to it today
jamesn: why's this a dependency for 1.2? this is now merging the changes that were already made?
mck: there was something that wasn't consistent - carmacleod can you explain?
carmacleod: firstly, the files with _IDL are only in the 1.2 branch, so that's where I had to work
mck: that's fine
carmacleod: the only changes I
did were to button_IDL.html and button_IDL.js
... i only took the setting of attrs out of HTML; the elements
were created there and set with role and aria-pressed
... now that's being done in JS
... I made comments on what I did
... the other code was there, but I added comments. and I
spruced up the comment at the top of the HTML file to say it's
simple as possible, etc.
... and I deleted some things that weren't relevant
... question for mck - I put aria-hidden=true on the SVG in the
mute button. i thought it was better. thoughts?
mck: shouldn't that be role=presentation or something? Why hidden? isn't it redundant?
jamesn: it's a child of the button, so should be presentational because of that?
mck: if it had a text equivalent, it should render, but otherwise...
carmacleod: it should be role=none because it's a child?
mck: unless it has an equivalent
carmacleod: either way you'd want it ignored and non focusable
mck: why would it be focusable?
carmacleod: IE11
mck: IE11 makes SVG focusable?
carmacleod: yep! yay...
mck: so... instead of aria-hidden, wouldn't role=none be better? if it's not being totally ignored ,that's the preferred technique?
carmacleod: okay, but isn't it role=none by default, because it's a button?
jamesn: it's a link with role=button
carmacleod: I can delete aria-hidden if need be
mck: we should use role=none
carmacleod: i can try it and see
what the screen readers do, but aria-hidden seems to have the
desired result
... otherwise it tries to read the name of the SVG file
mck: weird...
carmacleod: yeah, tell JAWS and NVDA about it
mck: so for guidance, maybe let's
say it's a last resort technique and shouldn't be
overused
... it can have severe consequences
... I Feel like we should avoid and minimize the use of
aria-hidden when we can, if the group agrees
MarkMccarthy: +1
mck: well =presentation on an image should hide the image, but... maybe SVG is weird
jamesn: it is
Sarah_Higley: would =none or
=presentation prevent a screen reader from stepping into the
SVG?
... because of that, I'd prefer aria-hidden
mck: to allow traversal for text nodes?
Sarah_Higley: yeah
mck: hmm. so when we say children
presentational is true, is it implicit or explict?
... if browsers don't base on the role, a browser bug? maybe
that's not an APG issue
... jamesn do you know?
jamesn: it's only an aria role
mck: so it should still be honored
carmacleod: i'd think
jamesn: that may not stop IE exposing the SVG
mck: true
carmacleod: it wasn't IE though,
it was Chrome and the others where JAWS was trying to read the
name of the file
... the sublink of the SVG changes from mute to sound, and the
screen reader would read the wrong information
mck: if it's a JAWS bug, I don't want to hide a bug...
jamesn: should we discuss this as part of _IDL ex or the main button ex? should we change both?
carmacleod: if we're discussing it, we need to change both, which I already did
mck: i just want to know if role=presentation does nothing. does this group think it's a bug in our code or the screen readers?
Sarah_Higley: is it a bug though? role=presentation strips the role, but the other info is still presented
mck: in accname calc, it doesn't matter, right bgaraventa?
jamesn: yeah, but this doesn't have text in it
Sarah_Higley: is the filename interpreted as text in an SVG?
BGaraventa: a presentational role in an SVG wouldn't do much because any text inside it would still be exposed
<jamesn> <svg aria-hidden="true" focusable="false">
<jamesn> <use xlink:href="images/mute.svg#icon-sound"></use>
<jamesn> </svg>
mck: so if there's no textual content, the screen reader doesn't present anything?
BGaraventa: well, it's a
different naming calculation. if something was in a description
it'd come through, but if it had a label, it's a probably
... either way, role=presentation on it shouldn't interfere
carmacleod: by the way, this is an SVG child we're talking about. the use href
BGaraventa: I'm not familiar with that, unfortunately
carmacleod: I'm just saying role=presentation or =none on the SVG won't have an effect on the child, whereas aria-hidden kills the whole thing
mck: so maybe this is a good
example to explain -when- to use aria-hidden
appropriately
... like a specific, good use of -hidden. this doesn't promote
overuse, but rather is specific to the issue
... just want to make sure we're providing the best guidance.
okay, let's stick with aria-hidden then
BGaraventa: I'm not sure who's working on the naming spec for some of these things we're talking about, but it's being worked on
mck: anything else for third
milestone review? [laughs]
... seems like everything else in there is pretty quiet in
there
... okay cool, this is looking good. we don't necessarily need
all of this ready for the WD jamesn
jamesn: yep it's good. essentially, group for listbox, meter, row/colindex won't go in
mck: suggesting we skip to tooltips if nothing for tab
carmacleod: I do
carmacleod: should the tabpanel take focus? right now it does, but it feels like an extra tab stop
mck: jongund?
jongund: that's what the tabpanel design pattern says
carmacleod: where?
mck: it's optional, when the tabpanel is static and has no interactive content or that content is at the bottom
jongund: let me look
carmacleod: not in the pattern, maybe the example
siri: the example has a tab stop on the panel
jongund: it's in the test cases for tabpanel, but i can change the tests
siri: no, i'd rather not
carmacleod: only if we all think it's a good idea
jongund: is there a way to test individual files now? seems I can only test directories
mck: that's a good question, i'm not sure
jongund: used to be able
mck: fixable if broken, we'll
check into it later
... in any case, tabpanel shouldn't be a required part of the
pattern, so not required here. question now is, should the
tabpanel be focusable?
jongund: I didn't have it focusable until I did the tests valerie wrote, where there were errors thrown. then I added the focus
<Sarah_Higley> @jongund running `ava test/tests/path/to/file.js` isn't working to test a specific file?
siri: I would prefer to have a tabindex on the panel, so a screen reader user doesn't miss anything and they can choose how to interact
mck: that's assuming someone is tabbing though
siri: if there's no focusable element inside the panel, i'd prefer to have it so I know I'm starting to interact with it
mck: in this case there's links inside all of them etc.
siri: but if someone uses this code and there's nothing inside, that might be an issue
jongund: yeah, there's nothing in the pattern
carmacleod: only in the examples
mck: sounds like an issue to address
carmacleod: we should probably say something in the pattern, either optional or required
jongund: nothing in the spec either
carmacleod: i can open an issue
mck: that'd be great
jongund: should I take it out? or leave it in?
mck: we don't want to do stuff here if it's not something good for usability - siri?
siri: I wouldn't keep it as
optional, i'd prefer always having the tabindex.
... in my opinion, i'd prefer to have it on the tabpanel
mck: speaking as a screen reader user, it seems extra to me, but i'll defer to group
jongund: issue with the slider here, the images are a link, but sometimes they might not be. so, possible you can miss content if you tab through things
carmacleod: everyone's different, yeah
jongund: might see it if you're
reviewing, but not tabbing. but if you're tabbing, maybe youre
not looking for interactive content
... i guess the real issue is consistency
BGaraventa: I recommend to make it focusable, if there's no interactive elements in it and so people don't miss it
carmacleod: i'll open an issue to add that advice to the pattern
jongund: so it'll be required or optional?
carmacleod: probably required, and keep it on this example
jongund: yep, planned on it
mck: in summary - this is about
specific language
... i think the issue is that our language doesn't say anything
about mouse hovered on a tooltip; that we don't generally
provide mouse guidance in APG patterns
... is this an actual conflict? should we change the wording?
or say it's not an issue?
carmacleod: tooltip is REALLY complicated. mouse is integral to using tooltips, mostly, but depends. it's not something I've been easily able to resolve
Sarah_Higley: I'd be in favor of adding wording about mouse behavior for tooltips, becasue it's easy to get that wrong
mck: across most of WCAG we don't
usually have mouse reqs, but for this specific instance,
there's issues around pointers etc.
... that's an exception to the norm right?
carmacleod: yeah
<Jemma> git --help
github: ... https://github.com/w3c/aria-practices/issues/811
mck: so what i'm hearing is we want to describe accessibility related pointer requirements in the APG pattern
carmacleod: i think so
Sarah_Higley: yes,
definitely
... the difficulty is how to describe it, certain interactions,
etc. but that can be part of another discussion
mck: i'd really welcome someone to draft some changes to the pattern in a PR, if someone can
Sarah_Higley: I can, i've been writing about tooltips lately. i think there's some stuff about dismissal that is controversial that'd be worth discussing before a PR
mck: a draft PR can contain anything, even if it'll go down in flames [laughs]
Sarah_Higley: okay
carmacleod: or add stuff to the issue before ready for the PR
group: thanks Sarah_Higley
Sarah_Higley: I planned on opening an issue anyway, so let's just go all in!
mck: well jamesn put his name on
this, so maybe we'll discuss next time. but a related question
for the group
... we were talking about flagging things about what's new in
1.2, a paragraph etc. something. once a PR is available, we can
discuss more
... but the rabbithole is about how well things are supported,
kind of what aria-at is addressing
... question becomes where to draw the line of what we say and
do
carmacleod: for instance, the
slider role
... increment and decrement
mck: so that's why jamesn said
issue 8 was related, known gaps for mobile
... i was thinking of things like key shortcuts, where Apple
explicitly said they weren't supporting it, so do we add
something saying so to the APG, etc.
... and I worry a little about maintainence etc. unless we find
a crafty way to automate
... it's a common question, wonder if anyone has any solutions
without creating maintainence problems
carmacleod: i ran into the same issues - not everything works everywhere. where do we stop
mck: that's the golden
question
... if we can come up with some criteria... like, if it's in
1.2 it's implemented in 2 browsers, etc. but that leaves a lot
of room for lack of adequate support
... unless some support gap is blocked, then i'd think that's
something we don't want to mention. but if there are major
blockers we know about and when they're being worked on, that
could be helpful
... but then i wouldn't want people to assume that everything
else is supported
Jemma: Korea's certified accessibility dev group is asking the same questions, according to the survey I did. this is a global, complicated, problem
mck: well, more fuel for the aria-at fire I suppose
<Jemma> regret+ ZoeBijl
<Jemma> https://github.com/w3c/aria-practices/issues/960
<Jemma> we just talking about the testing
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 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/tryign/trying/ Succeeded: s/you make/to make/ Succeeded: s/problem/problems/ Succeeded: s/so like a survey or something may be useful/ according to the survey I did/ Succeeded: s/speaking as a screen reader/speaking as a screen reader user/ Succeeded: s/CHrome/Chrome/ Succeeded: s/defualt/default/ Succeeded: s/presentatioal/presentational/ Succeeded: s/teststing/testing/ Present: jongund CurtBellew MarkMccarthy Matt_King carmacleod Jemma BGaraventa Scott_V Siri Found Scribe: MarkMccarthy Inferring ScribeNick: MarkMccarthy 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]