Meeting minutes
https://
Wrapping up 1.2 release 1
next meeting date is Jan 26.
mck: I would like to talk about going back to weekly meeting schedule
to talk about APG redesign project issues and more
… any feedback to improve meeting efficiency or any other meeting agenda?
1. navigation treeview example
PR 1558, 1607, 1109 are waiting on Matt's review
<CurtBellew> hiya
discussion is about a11y feature in the treeview example
"Activating a tree item moves focus to the beginning of the new content, ideally a level one heading with content that matches the name of the tree item that was activated. Focusing on the heading informs screen reader users that navigation is complete and confirms the destination. This behavior is appropriate when common or important use case scenarios assume users want to start interacting with the loaded content after activating the tree
item. Note: Keyboard users will need to navigate back to the navigation tree to view other pages. To optimize keyboard efficiency, design a layout that logically locates the tree immediately before the content display area in the Tab sequence."
this the info about our design decision
mark: it sounds resonable
mck: my struggle is the part, "If activating a tree item changes content on the page without triggering a browser page load, i.e., works like typical single-page apps, the focus position after the content load significantly effects efficiency for keyboard and assistive technology users. "
sarah: I think it is clear enough.
mck: I didnot want to use the word, "single app" but it seems to help engineers's understanding
<siri> For accordions we use enter key to expand, for treeview which looks like accordion , right and left arrow to expand/collapse.
siri: the example can be confused with accordion vs tree view in terms of keyboard navigation, accordion use tab to expand, tree view uses arrow. how would users know this difference?
Sarah: visual context makes a big difference to show tree structure.
mck:
jon: found a bug. I will fix it and push to the repo
color picker slider
<Jemma> https://
Jon: I've updated the focus styling, the main thing today is if it has the behaviors and features we want
Jon: there's two example pages, one that has the buttons and one that doesn't
Jon: they're both in the same PR. It used to be one example, now it's two examples
Matt: the new example with the buttons for mobile, can that be in a separate PR? Because the existing example that's already published is the one that doesn't have the buttons but it doesn't have the improvements for high contrast and SVG
Matt: so that should be much more straightforward to just merge
Jon: the old example is ancient
Matt: so then the other, new example is the one with the buttons, and I would prefer that to be in a separate PR, because that's making more changes, so I think we need to review it separately
Jon: OK
Matt: so the updates to the existing example: the title says color slider using SVG. We don't need to have "using SVG" in the title, do we?
Matt: that's not a distinguishing feature of this example, is it? We don't have a color picker that doesn't use SVG
Jon: the old one was using CSS. But [now] we don't have one that's not using SVG
Jemma: the color viewer slider example with mobile is separate? I was testing this on my iphone, and the reason mobile is separate is because it has the buttons, right?
Jemma: one thing I found is when I use the buttons, it decreases by 10. But it doesn't annonce the new value. Other than that, it looks OK in a mobile device
Jon: so when you press the button, it doesn't change the slider?
Jemma: it does change the slider, but it doesn't say the value
Jemma: I added a screenshot and speech-to-text output in the review. Other than that, it works well on mobile
Jon: is that a problem with the example, or a problem with the screen reader?
Jon: so if you swipe back to the value, is the value that is displayed and announced incorrect?
Jemma: when the focus is on the button, and when there is a change of the value, it does not announce the value change. But when the focus is on the slider, it works perfectly.
Jemma: the case is, when the focus is on the button itself
Jon: you think we should add a live region to the value, so when you're using the buttons you get the change?
Matt: that would cause a problem when the focus is on the slider
Matt: I mean, the focus is on the button, so you're not going to expect the value to be announced. I'm not sure what you're saying is what should happen
Jemma: I guess we don't announce the current value when the focus is on the button. That's my question: whether that's the way it should be or not
Matt: it would be friendly, but I guess the buttons are kind of a hack, because if you have these buttons usually you wouldn't have a slider
<Jemma> https://
Jon: part of the example is to illustrate that there isn't good mobile support for sliders. So if that's important to you ,maybe you should think of something else
Jon: a real UI designer would probably take a look at this, and think "eh I don't want to do this"
Jon: the last time we had APG 1.1 people saying we're not talking about mobile support
Jon: so we gotta show them, if you want to support mobile, this is what it looks like
Matt: it seems like kind of a funny approach
Jemma: when focus moves onto the slider itself, it shows the value and everything
Jon: it does seem weird, why do we still need to do stuff like this
Matt: maybe add a note, we can use the wording we already have in the pattern, when the APIs exist then this example will be obsolete
updated indexes to include high contrast support information by jongund · Pull Request #1607
Sarah: though there's also that WCAG 2.2 follow-up to Pointer Gestures
<Jemma> great!!
Matt: Jon, can you explain to me the bullet under accessibility features (will copy)
<mck> MK: want to know meaning of: • Use of SVG enables high contrast support by including additional background rect and circle elements to provide contrast for the focus and hover border
<mck> styling of the buttons and sliders.
Jon: this is one of those examples that started last summer, and is still waiting to be merged. In between then, Carolyn taught me about use of currentColor, so I haven't integrated that in
Matt: can you change that documentation to reflect what you've done?
Jon: I don't think we need that bullet anymore
Matt: the placement of the [unheard] above the thumb?
Matt: I think that's different from other examples, and an accessibility feature
Matt: I'm asking about this bullet right here:
<mck> AX feature: • The placement of the slider value above the thumb supports users with low vision by allow them to more easily see the value of the slider as they move
<mck> the thumb.
Siri: regarding that, will it cause any issues for users who are using magnifiers?
Matt: so we're listing that as an accessibility feature. Are we saying that that visual design, we want to highlight that as something people should do when they're designing sliders to improve accessibility?
Jon: this is one of the improvements from our previous example, so that's why I listed it as an improvement. I think it's important because it's talking about low vision
Jon: it's one thing people complained about, that it's so screen reader-centric
Matt: I just want to make sure there's concensus from other people that this is an aspect of the design that's important for accessibility
Jemma: I think it's very important for usability too, because you can see the value change as you move the thumb
<mck> mk: can we delete this: • The svg images have an attribute focusable="false" to mitigate a bug in Internet Explorer 11 that sets focusable to true when an svg image is inside
<mck> a button element.
Matt: I want to know, can we delete that, or should we leave it in there? We don't have that in any other examples
Jon: You'd have to ask Carolyn, since that was her suggestion
Matt: did we do this in a lot of other examples where we don't document that we've done it?
Jon: as far as I know, this is the only example where we put SVG in a button element
Matt: I guess I'm not following that 100%
Matt: oh, so this can be deleted from the version that doesn't have the buttons
Jon: OK, I'll go through and delete that
Matt: so this is specific to IE11. I guess it's ok to mention that even though we're not formally supporting IE11
Jemma: I would vote for not having it here
Matt: OK, we are at the end of our time. This is helpful to me for being able to wrap up editorial review on this slider. I think the one that doesn't have the buttons is a lot closer to a slam dunk
Jemma: we already have the focusable information in the table
Matt: I wonder if it belongs in the table, or in accessibility features
<Jemma> jon: treeview navigation bug was fixed.