<Jemma> Meeting: ARIA-APG

<scribe> scribe: MarkMccarthy

[chit chat, waiting for participants]

Next meeting dates

<Jemma> Subsequent meetings: December 15 and Jan 12.

<Jemma> No meeting December 29

mck: meetings are on Dec 1 and 15, may revisit January meetings on the 15th meeting

planning next priorities

mck: thinking ahead to first half of 2021. a lot of our work is reactive (responding to PRs, questions, issues, etc)
... some of that is just because of the way the community works and talks to each other

<Jemma> next priorities include ARIA 1.3 support

<Jemma> Redesign project

<Jemma> Navigation systems

<Jemma> Coverage

<Jemma> Code quality

<Jemma> Mobile support

mck: but i'm thinking of how to be more focused on key areas, overarching themes in issues, or chatter outside of communities that could be related to APG
... what does everyone think of that? or other input on priorities or reactivity vs. proactivity? thoughts on the list [above, pasted by Jemma]?

Jemma: so the redesign project is what we talked about with EO right?

mck: yes, moving onto WAI website

Jemma: i'm interested in mobile support. we've made significant progress on quality with our examples, but what are we doing for mobile?

mck: i think we're at the beginning of answering questions around navigation - not quite done ---

Jemma: what else needs to be done?

mck: mostly becuase we have lots of issues outstanding; lots of examples lacking cohesion; I don't think we've got good guidance at the moment
... things will have to stay in draft until we have some consistent examples
... the updated menubar from Jon and then Sarah's work...once we get those in we're off to a really good start

carmacleod: that's probably when we should put that new section in. that is, once those are done, just put em in

mck: i'd love to, hopefully by the new year. but time is short

carmacleod: indeed, lots to do. if we have focus on those three things getting polished, and finishing the draft of the new section, it's _only_ four things

mck: those are all listed in issue 89

<Jemma> https://github.com/w3c/aria-practices/issues/89

mck: mobile is probably the biggest untouched thing, and we're getting good feedback about compatibility

Jemma: maybe we can set micro and macro priorities. redesign project will take a long time, but nav systems could be done in 6 months let's say
... so i think we'd benefit from setting short and long term goals

mck: one thing about redesign: it's kind of standalone since it's not quite the core of what we do, it's improvements to delivery. so i'm comfortable having vendors etc. work on that
... whereas mobile support and nav systems are the core of what we do

Jemma: +1
... and, i think some limitations of our examples (like responsive design) will be solved during the redesign

mck: yes and, the mobile item on the list here is about providing patterns for folx who want to implement patterns for small-screens and/or touch devices
... maybe we should clarify "mobile support." for some patterns, there might not be enough support on the mobile browsers. so maybe _those_ need warnings or something similar
... in other words, mobile support may mean saying it's _not_ supported

<Jemma> +1 for clarification of "mobile support" to distinguish it from delivery platform issue, APG redesign project.

carmacleod: i wonder if we should look around and try to recruit more people. we're taking on a lot of work and some of us, at least myself, have no experience working on mobile devices
... it's a big area, and i personally feel i can't contribute enough. but there _has_ to be folx out there that are wizards

mck: YES. to do it well, we certainly may need more people

carmacleod: jamesn, maybe the slack channel would be a good avenue to post?
... or maybe we could all discuss who some of the right people would be

jamesn: when i come across those that seem receptive to our work, I do try to recruit them. but open ended things like that tend to garner negative responses or the wrong people

Jemma: so we're looking to figure out what the major problems are with touch devices and other small screens

mck: eventually, we want the work we do to support the whole community, not just us. in some of these cases, multiple flavors of an example might be good
... for instance, things might be done differently if using touch or small screens
... some of what mobile support entails is workarounds, and we don't always specialise in workarounds. we demonstrate ARIA.
... as we expand our scope, we might want to have _some_ examples that _do_ have workarounds to get information out there, but then streamline them later as we continue working

Measureing success

Jemma: so our first priority next quarter is working nav systems, this other stuff running concurrently?

mck: yes
... if someone wants to help lead this mobile space, recruit, etc., that'd be awesome

Jemma: i can help! but would love some other hands too

mck: so maybe a recurring agendum once a month, progress reports etc.
... I'm feeling that we'll need to work on having measures of success in order to keep money flowing and having vendors help us out
... so "Reach" is one kind of success, and give us some hard data about things. so blog posts or MDN resources, etc. Anything that can share our content
... if anyone has any ideas on how we can do this, would love to hear!

carmacleod: i think the CodePen buttons are huge for reach

jamesn: as long as people don't share their modified version of the APG example as the de-facto

mck: definitely, that seems to have been very helpful

jamesn: i'm wondering if we can get metrics from the website; page views etc.

mck: that'd be good, boucoup can look into that, as can Boaz

jamesn: MichaelC might know, but he may not

mck: Boaz is pretty good at that

Jemma: Shawn shared the analytics data for the links, so maybe she has some data too?
... jamesn, did you mean getting feedback from CodePen clickthroughs?

jamesn: no - saying that people will save the modified codepen as a reference, rather than the "official" example

Jemma: gotcha

mck: does anyone have ideas of solid success measurement?

Jemma: not quite success meausrsement, but I'm thinking about possibility of integrating ARIA-AT etc. on CanIUse

mck: definitely investigating it
... if anyone has ideas, let us know! it's nice to go out and talk about what you've done besides just listing off a pattern you worked oon

<Jemma> https://a11ysupport.io/

wrapping up

mck: nav treeview example looks to be coming together well

<Jemma> https://github.com/w3c/aria-practices/pull/1558

mck: carmacleod, you just have to look at functionality?

Jemma: i can do more work on the a11y review but the design review is done

mck: there was some discussion on aria-current; is there a common visual convention we should be emulating?
... i.e. what's the most common visual indicator of what the current page is?

Jemma: usually a border, font, or color change. haven't seen arrows other than something like an accordion

carmacleod: haven't seen an arrow in a while

jamesn: --it's an old thing

carmacleod: maybe flipping the colors, or bordering

mck: but that's not WCAG compliant?

jamesn: it could be; as long as the luminosity changes, it's not relying on color alone
... luminosity _AND HUE_

Jemma: visual design, I think i'm confident on what i've done

mck: great. did you find anything else that needed to be addressed?

Jemma: i'm not sure how we can deal with touch target size, since it's not responsive

mck: they're too small?

Jemma: yes
... color contrast review is good, that should help out Jon a little

mck: so re: touch target, if those things are too small, is it difficult to resize or do we have room? it's a AAA requirement though?

Jemma: yes, i'll have to double check

jamesn: so, is it just me or is the focus movement really weird?

carmacleod: yes

jamesn: it's fine for a keyboard user, but if a mouse user clicks on an item in the tree, it shouldn't move _their_ focus

mck: okay, but where's their focus beforehand?

jamesn: fair enough - but i shouldn't move it away when i just click in there. what if I wanted to use the arrow key?

mck: true! if you were using click to bring focus in the tree...

jamesn: yep, which isn't uncommon

mck: so that focus change is likely happening based on the link getting activated

jamesn: yep

mck: it's _really_ helpful for a screen reader user, especially in a SPA, which i suppose is our envisioned ideal audience

jamesn: but a visual keyboard user _won't_ want their focus to move when they want to expand the tree

MarkMccarthy: if shift-tab even _goes_ back to the tree

jamesn: yeah. i think focus should stay where it is, and it's up to the screen reader user to navigate away in the way they want

carmacleod: it seems really nice to me, arrows and all

<Jemma> https://raw.githack.com/w3c/aria-practices/update-tree-nav/examples/treeview/treeview-navigation.html#home

jamesn: as a keyboard user, i go to the apply page "oh the info I wanted wasn't on that page, it was on tuition page" and my focus is gone and I have to get back to the tree
... an _application_ is different; on a _webpage_ you usually want to read stuff

mck: most of the time in treeviews, the whole thing gets reloaded so you're back at the top
... for an SPA, we've had good feedback at Facebook about primary nav activations only refreshing part of the page

jamesn: Facebook is different from typical webpage navigation on a webpage
... if you select something on Facebook nav, you probably are going to spend time _in_ the page you selected. a typical webpage, you might be reading/scanning through info. it seems very different to me

mck: most of the time when you click links in typical nav, you start over. so you usually don't have that type of behavior anyway

jamesn: i don't think it's that unusual these days

Jemma: +1

jamesn: so I think if we're targeting correctly, that's okay. but this pattern seems to be optimized for a screen reader user, not a keyboard user

mck: something in the accessibility feature section noting these difference might be a good approach
... could folx also give feedback on the caution on top of this?

carmacleod: needs something to stand out, a yellow box

jamesn: yup

mck: could someone make a <span> style for me to apply?

carmacleod: also missing the green box we usually have
... oops, nevermind. the box is there. so same sort of style except yellow for caution

mck: yep, having a caution style would be good

Jemma: so we're adding a note about use cases for the tree view, that approaches may have to be different.

mck: i'm fine with, for mouse users, focus not moving, or moving it to the tree

jamesn: 100%

carmacleod: that's not quite how the disclosure works though

<Jemma> https://raw.githack.com/w3c/aria-practices/update-tree-nav/examples/disclosure/disclosure-navigation.html

mck: james, what do you think about that?

jamesn: the menu is different. once it closes, focus _has_ to leave it.

mck: is there a strong argument for making them different then? sometimes you want a pattern because you _do_ have a different kind of experience

jamesn: my general rule is, if the thing focus is on is still on the page, focus should stay with it.

carmacleod: they're same page links though

jamesn: yes, but in this case they don't look like that, so someone might not expect it

CurtBellew: there are other links on the page, outside the tree (or a link _inside_ tuition) that look like links. i see james' points - conceptually they're navigation to me, not links

jamesn: i'm against this going forward as is

CurtBellew: +1 - our answer is usually leave focus where it was activated

MarkMccarthy: me too - +1

carmacleod: unless it's a same page link

mck: still kind of debating the subtleties between menu, tree, disclosure. it's okay if we can clearly explain the reason for difference

carmacleod: it's the arrow keys

mck: that exists in menubar and disclosure too
... the new disclosure pattern has a link and a button. my assumption is the link moves focus, the button expands the view
... i'm kind of wondering if this is a visual styling issue

jamesn: i'm also wondering if this fails 3.2.2
... --change of context.

CurtBellew: that's what i was thinking too

<Jemma> https://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html

mck: so it's not an input in that sense, but there's a little bit of ambiguity here

jamesn: [reading the success criterion definitions]. in my reading of that, if it was tabbing through it wouldn't be a single function

mck: you could easily have a button in a toolbar that moves focus

jamesn: a button is there and seen as being okay (it's expected to change). it is ambiguous, yes.
... these "same page links" are being exposed as treeitems
... and look like that to visual users

<Jemma> thanks for exteneded scribing, Mark

mck: even though it's a link in the code, we have to remove the link behavior, unless someone is using a tree to navigate. by the logic here, it'd be illegal to use a tree if it loaded a new page

jamesn: if it does that, it's not technically a tree. yes, it's ambiguous. as is, it's very confusing

mck: is it clearer if we change the click behavior?

jamesn: clearer, but doesn't help a sight dependent keyboard user

MarkMccarthy: we are over time

CurtBellew: this is an interesting discussion!

mck: i don't think there's one right answer. i think there's more conversation to be had

jamesn: there are some places where you know the user is going to want to interact with the tihing on the right hand side
... it's almost an exception to move focus rather than a rule

CurtBellew: thinking of a document on the right side, nav links on the left (onedrive online or similar)

jamesn: file explorers work that way too

carmacleod: you stay in the tree on the left until you tab to the right side in Windows' File Explorer

MarkMccarthy: yep

mck: we'll have to sort things out, seems like this is difficult

CurtBellew: the roots run deep

[playful jeering]

<Jemma> LOL - roots run deep

mck: thanks everyone, sounds like we could use some more deep dive discussions

carmacleod: VS Code could be worth some exploring too. clicking keeps focus in the tree, enter focuses into the code

jamesn: that's not what _I_ have with VS Code (on the Mac)

carmacleod: I'm on Windows.

[scribe has to drop off]

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/present +//
Succeeded: s/anda/and/
Succeeded: s/definitly/definitely/
Succeeded: s/?//
Succeeded: s/AND HUE/_AND HUE_/
Succeeded: s/focus'/focus/
Default Present: mck, Jemma, carmacleod, sarah_higley, jongund, Jamesn, MarkMccarthy, Bryan, CurtBellew
Present: CurtBellew Jamesn Jemma MarkMccarthy carmacleod mck
Regrets: Jon jongund sarah_higley
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.)