<Jemma> scribe: sarah_higley

<mck> link to agenda: https://github.com/w3c/aria-practices/wiki/September-1%2C-2020-Agenda

Future meeting agendas

matt: our next meeting is on the 15th of september, and then on the 29th

APG examples code review update

matt: Valerie provided some feedback, made a couple updates

sarah: I should be less busy soon, and will be able to finalize the wiki PR by the next meeting

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

matt: I saw Valerie has been using the notes and making good comments in code reviews
... so last time you had the draft of the wiki page in a branch, so people would have to clone the wiki and check out the branch, right?

sarah: yes
... I will be finding a way to make this easier to review, so people don't have to clone it locally

<Jemma> https://github.com/w3c/aria-practices/tree/wiki

matt: you can see an outline of what sarah has included in the issue

Color contrast of selected date in Date Picker grids

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

matt: Carolyn made a draft PR, #1479
... this was in response to an issue that when the selected date is not focused, the color contrast was insufficient
... there was a relatively simple fix for that, but then Jon commented in the PR that there was also an issue in high contrast mode related to the selected date
... so do we need to include that in this PR, or should we go ahead and merge #1479?

<Jemma> https://github.com/w3c/aria-practices/pull/1479#issuecomment-666437039

james: couldn't we make the number of the current date bold? Wouldn't that be an easier resolution?

matt: I'm open to anything the group says is a good idea. What do you think, Jon?

(Jemma is the link master)

Jon: we're not using borders in HCM to indicate if something is selected. I have to go back and look at it

matt: this is for both combobox and datepicker

James: so if the text of the selected one is also bold, it would not fail color alone

matt: are there other examples, is that consistent with what we're doing in any other places?
... is there any concern about consistency of approach across other examples?

jon: it's visually subtle

james: it's in combination of the other things, so even if the color difference is low, then the combination of all the things together

(Jemma -- that is your official scribe name now :D)

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

matt: you can see the preview link in the PR. You have to select a date, then move focus away from it

<Jemma> https://w3c.github.io/aria-practices/examples/dialog-modal/datepicker-dialog.html

<Jemma> change Carolyn made - background-color: hsl(216, 80%, 51%);

<Jemma> color: white; from background-color: hsl(216, 80%, 92%);

Jon: we had another color setup before, but people complained that it didn't look like a regular datepicker

example link: https://raw.githack.com/w3c/aria-practices/issue1478/examples/dialog-modal/datepicker-dialog.html

james: I don't understand why the dotted border doesn't meet the color ratio
... the border isn't a light blue, it's a dark color

jemma: regarding James' suggestion to make it bold, I think that's a good idea

james: we have a problem here, where the cursor focus one is different from the selected one. Is that intentional? So when you mouse over it, it's the light blue color. Is that ok?

jon: I'm fine with this, and if we want to make it bold, that's easy

james: I don't think this needs to change. I don't understand the original issue, I don't see anything that fails WCAG in even the current example

curtis: I think even on the date that's the current one that's moving around, there's even a border there so it works in high contrast

jon: yeah, I think it looks good in high contrast

curtis: the dotted border, as far as the non-text contrast. I assume you're just checking the contrast of the dots. That's not something I've thought of before, the dotted border with respect to the non-text contrast. But that works, right?

jemma: I think the original complaint is about the light blue border

james: I think I might see what he's complaining about now
... so if you open up the original example and you click anywhere else in the example, it does not have the border anymore because it's not in focus. So the current selection has nothing else to indicate it
... you have to click on white space within the grid
... so this new one is much better, it's good. Ship it.

matt: do people agree with James? If it doesn't have any negative consequences on HCM

jon: OK, it's fine, it's just in HCM a date with tabindex="0" it has no indication when focus is out of the grid

james: yes, but can we just open a separate issue?

matt: you don't need to indicate which one has tabindex="0" when it's not focused, only the one that's selected. If the grid isn't focused, the date with tabindex="0" doesn't matter

jon: the one with aria-selected is always indicated whether focus is in the grid or not

Site navigation systems (menus) plan

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

matt: the goal here is to simplify by taking baby steps
... we're in a situation where there's massive opportunity for improvement, and if we talk about all of them at one time, it's really easy to get buried in lots of details and potentially contentions discussion and so forth
... but if we just iterate and make things better one step at a time, then we can over time get to a place where more people are happy and we're better off

<Jemma> Proposal: Plan to resolve this issue:

<Jemma> Revise nav tree example to represent mythical university, emulating behavior of disclosure nav pattern.

<Jemma> Remove or modify navigation menu button example: If we keep, should it be a single button that shows the top-level of the nav?

<Jemma> Merge initial version of navigation systems pattern.

<Jemma> Modify introduction of examples included in navigation systems pattern, including appropriate cautionary notes where appropriate:

<Jemma> Modify introduction of disclosure example to link to site navigation pattern.

<Jemma> Modify introduction of menubar navigation example to caution against inappropriate use and link to navigation system pattern.

<Jemma> Modify introduction of tree view navigation example to caution against inappropriate use and link to navigation system pattern.

<Jemma> Modify menubar navigation example to replicate behavior of disclosure example:

<Jemma> Eliminate loading of separate pages

<Jemma> Implement aria-current

<Jemma> Consider additional examples and issues to address:

<Jemma> Is there other guidance that should be included in or linked to from the navigation systems pattern?

<Jemma> Should we build more examples, e.g., tabbed navigation, megamenu?

matt: right now I'd like to just take small steps
... so what I have here is a proposal of what some of those small steps might be
... so there's essentially five steps in this plan, and there are some sub-steps.
... I think if we can get the first three done in the next month or two before 1.2 is finalized, I think that would be a lot better
... not perfect, but I think it would be really meaningful
... the two preperatory steps: one is to do something about treeview, and one is to do something about menubutton
... and then we would have this nav system pattern PR that we could look at that would reference at least three or four existing examples and provide some basic guidance
... that would take care of at least half of the complaints that are in issue 353
... the first step in the plan would be -- we do have a treeview navigation example, but it doesn't match up at all with the disclosure pattern. So the first would be to modify the treeview one so it perfectly emulates the disclosure one
... there's a few details like whether we use aria-selected or aria-current
... the next step would be to decide what to do with menubutton. That might be a slightly deeper discussion. We have a menubutton navigation example right now, and it also doesn't emulate what's done with Mythical University
... the question is whether or not we should do that one. Because maybe it would be too similar to menubar, or just maybe not aligned at all
... then the third step is we could actually look at this draft PR I have, and I think we
... we'd be able to merge something really basic, so we'd have something to reference in the main document
... then we could go and modify the wording of each example to add the appropriate warnings
... so these are the four steps I'd like us to get through in the next three months

jon: so the first thing is I think all the examples should have a single look and feel so people have a good idea of what they're comparing

matt: so do you mean beyond the content, Jon? I think they should all work like the disclosure pattern so when you activate a link it just changes a content region on teh page
... but do you beyond that, into the visual design?

jon: I think the more they look alike, the more people will only compare based on what the differences look like, and so you open yourself up to that

matt: so a tree already looks so different, so I don't know how you would make that look like the disclosure one
... the disclosure one is the most recent and most discussed and most preferred, so if we were to emulate one, it would probably be that one. Do you agree with that, Jon?

jon: I don't know if I agree with that, but if that's what the group wants to do

matt: I do agree with your basic assertion that the more similar they are, so the visual appearance doesn't cause someone to gravitate to the wrong one for the wrong reasons
... I think we want to minimize that, and that was your basic point, right?

sarah: I think if we pay attention to things like text, colors, padding, borders, etc. we can make the visual style consistent across different types of controls

jon: isn't the disclosure pattern more like an accordion, because it closes things that have been opened automatically?

matt: that's the menubar too

jon: I just want to make sure, because some people say "why aren't you including accordion?"

matt: from an ARIA perspective, it's actually not that different. But an accordion isn't an actual widget. Just like the nav menu made with disclosures, it's just a hybrid mixture of ARIA components used to achieve a specific purpose
... it's just that accordions don't look like that thing, and aren't usually used
... but you could say that the only difference between teh accordion example and the disclosure nav is that the disclosure doesn't use headings and shouldn't
... they're also arranged horizontally while an accordion is usually vertical
... but your point is well made
... but I don't think using the word accordion would help

jon: what about just tabbing through? Do we want an example where people just tab through all the links?

matt: I revised the intro to the site navigation to say that if you have a list of static links and there's nothing complex about it, just add a list of links to the page and add aria-current to the current one
... and that's added to the PR, and there's text that says if you're using anything more complex than that, here are examples. And we'll list different considerations for each

jon: there's even some examples I've seen out there with dropdown menus, where you tab through them

matt: our disclosure is already like that, if you take the optional arrow key behavior out

jemma: yeah, I saw that a lot, what Jon described
... your idea is coming from the conceptual distinction between navigation menu vs. application menu, right? So right now we're only talking about site navigation menus, right?
... do we need to worry about application menus at all?

matt: not in this PR

jemma: in number 2, you said remove or modify navigation menu button example. How does removing that example help resolve this pattern?

<Jemma> https://w3c.github.io/aria-practices/examples/menu-button/menu-button-links.html

matt: right now I could remove it from the pattern. It's just that right now we have this example called navigation menu button example, so by its name and nature it introduces itself into this pattern
... so maybe we could talk about this in the next meeting, what would be the considerations for what we want to do there
... my next step here would be to make an issue for each of the steps in this plan
... but before that, I just wanted to get feedback on the approach of doing it incrementally
... e.g. is there something big missing here, is it in the wrong order...

jemma: I think the process is right, but I'm just trying to understand

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

https://github.com/w3c/aria-practices/pull/1492

sarah: I like the incremental approach. But after all these steps, would we have a chance to discuss potentially more contentious topics like making the menubar example content more like an application menu?

matt: yeah, I think after some topics like whether we want to add more examples, we can also talk about whether to remove them
... oh, so one thing we might also want to do is make some changes to the intro to the menubar pattern, or intro to the treeview pattern to reference the site navigation pattern. I should include that in the list

But once we get the right guidance associated with each of these patterns, we may even want to revisit things like is mythical university -- do we want to change all three or four or five patterns to have different content

matt: I think those would all be really valid questions

<Jemma> https://raw.githack.com/w3c/aria-practices/issue89-navigation-systems/aria-practices.html#navigation-systems

sarah: yeah, I like that approach, and the incremental approach

jon: I think guidance on why I would want each of those patterns

matt: let's get the basics done, and if doesn't answer all teh questions people need answered, then we can do more when needed

sarah: could we add a step about updating link structure between examples and site nav pattern?

matt: yup, I understand what you mean

Review open pull requests

matt: the carousel one, Jon I expect that to get merged this week
... so that one is basically done with the review process. Radiogroup is also done, and I merged it
... and merged the selected state on
... this week, the three I propose we prioritize are the menubutton examples -- there are a couple todos in that one for you, Jon
... and the color picker slider changes
... and then, Sarah the third one on the list is one where I was looking for a review from you. I'd love to merge it before Thursday
... I'd love to have Valerie make the changes to add that codepen button to every page and be functional

sarah: sounds good, will review

matt: so we need functional and visual design reviews on menubutton and color picker

jemma: I assigned myself to visual design review

matt: can you do the functional review as well? The goal is to get these merged before the next meeting

jemma: sure

matt: just to make sure none of the functionality was changed or broken

jon: the biggest change would be to color picker, the additional button so we support mobile devices. Everyone should look at that and ask if that's something we want

matt: actually, James, could you look at that one?

PR link: https://github.com/w3c/aria-practices/pull/1472

<jongund> https://raw.githack.com/w3c/aria-practices/update-slider-1/examples/slider/slider-1.html

james: this is just the example of the slider, right? We're not saying this is a good example of making a color picker

matt: this PR isn't about changing it to a different kind of example, but if you think this isn't a good example that would be a separate issue that would be worth describing

jon: it's just to demonstrate buttons

james: so this is just about adding buttons to make it work on mobile for lack of support on mobile, right

matt: correct

james: the correct advice is just to say not to use a slider, but this is the ARIA practices, so I guess we can't do that
... I'll take a look at it

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)

Present: mck jongund Jemmaku JamesN curt CurtBellew Sarah_Higley
Regrets: bryan mark Carolyn
Found Scribe: sarah_higley
Inferring ScribeNick: sarah_higley

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.)