Spetember 3, 2019 Authoring Practices Task Force Telecon -- 03 Sep 2019

<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

Future meeting agendas

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

Third Working Draft Milestone

<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

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

Tab carousel example

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

Tooltip conflict

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!

APG Language for new ARIA feature

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

- DRAFT -

Spetember 3, 2019 Authoring Practices Task Force Telecon

03 Sep 2019

Attendees

Contents

Future meeting agendas

Third Working Draft Milestone

Tab carousel example

Tooltip conflict

APG Language for new ARIA feature

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output