<Jemma> scribe: sarah_higley
<mck> link to agenda: https://github.com/w3c/aria-practices/wiki/September-1%2C-2020-Agenda
matt: our next meeting is on the 15th of september, and then on the 29th
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
<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
<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
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
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.)[End of scribe.perl diagnostic output]