<mck> CAIR: Matt King
<Jemma> I am at epub meeting but coming over to this meeting soon.
<Jemma> Jon is requesting to add meeting agenda
<Jemma> menubar navigation about a default action (e.g. following a link) for the expandable menu items
<Jemma> https://github.com/w3c/aria-practices/wiki/October-27%2C-2020-Agenda
<Jemma> scribe?
<scribe> scribe: carmacleod
<Jemma> next meeting is November 10
mck: when will ARIA be published?
<Jemma> Menu button improvements: Review in progress
<Jemma> Jon: Issue 1526 to revise Navigation Tree Example to match Disclosure Navigation Example
<Jemma> Val: Codepen Button Implementation Project
<Jemma> Matt: Guidelines for aria-level attribute
<Jemma> Matt: Change log section of appendix and supporting wiki page
carmacleod: I think James said Rec by mid Jan?
mck: So PR by mid-Dec
... we will try to keep on track with ARIA 1.2. May be able to
slide a few more codepen examples in...
<Jemma> https://github.com/w3c/aria-practices/pull/1532
mck: need more reviewers
ZoeBijl: I can review
mck: Preview link in the PR
jongund: there were styling
issues, but maybe they're fixed?
... they seem to be fixed
<Jemma> aria-level https://github.com/w3c/aria-practices/pull/1109
mck: maybe this is ready to go in
then
... I have finished merging into the publication branch -
there's a link in the agenda
... Let's talk about menubutton
mck: there was some question about HCM documentation
<mck> https://github.com/w3c/aria-practices/pull/1401#issuecomment-713797913
mck: we had some text about transparent borders, but that text got removed
<mck> Because transparent borders are visible on some systems with operating system high contrast settings enabled, transparency cannot be used to create a visual
<mck> difference between the element that is focused an other elements. Instead of using transparency, the focused element has a thicker border and less padding.
<mck> When an element receives focus, its border changes from 1 to 3 pixels and padding is reduced by 2 pixels. When an element loses focus, its border changes
mck: we proposed another wording, but I don't know if that wording is good
<mck> from 3 to 1 pixels and padding is increased by 2 pixels.
mck: is this wording ok?
jongund: looks ok to me
<mck> Is this correct: Because enabling operating system high contrast settings can remove color variations used to distinguish buttons and menu items from plain text, focusable
<mck> elements are given a 1 pixel border.
mck: when you don't have high contrast enabled, how are they styled?
ZoeBijl: for which example?
mck: when you go to high contrast mode, does the border disappear?
jongund: It still has a
border
... When not in high contrast mode, the border color and the
background color are the same - blue
<sarah_higley> "Because background color and text color styles can be overridden by operating system high contrast settings, a separate border style is defined so that the button will still have a visible boundary when high contrast mode is enabled"
<jongund> +1
mck: awesome
carmacleod: +1
jongund: sounds good
<Jemma> I like Sarah's writing because it is easily understandable to developers.
<Jemma> "separate border style" made things clear.
<Jemma> https://github.com/w3c/aria-practices/pull/1472
<Jemma> https://raw.githack.com/w3c/aria-practices/update-slider-1/examples/slider/slider-color-viewer.html
<ZoeBijl> Suggestion: “Both background colour and text colour can be overridden by an operating system’s high contrast setting. A separate border style is added to the button to maintain a clear visual boundary in those situations.” (alternatively replace “in those situations” with “when high contrast mode is enabled”)
mck: there were some pretty significant changes to the slider, so looking for feedback
<sarah_higley> +1 to Zoe's HCM wording
carmacleod: either wording works for me
mck: Sliders are not natively
supported the way they should be
... are the buttons necessary for mobile?
Jemma: I quickly tested on iOS. Since our example is not responsive, I had to zoom in to use the buttons
jongund: if you tap on the rail, it will move the slider to that position
mck: need the buttons for smaller
increments - difficult with tapping on rail
... I think it's interesting to keep the buttons in the
example, but not mention then in the pattern. Or should the
pattern include them?
jongund: maybe there should be a
note in the pattern saying due to missing api on mobile we've
added the buttons
... when will this problem be fixed? soon?
mck: not that I know
jongund: so there's still documentation to add about the buttons
mck: so we should still keep this
as a draft pr
... need more feedback - should we put this in? In terms of
timing, we might have all of November to look at this.
carmacleod: I've added my name to the review list
mck: 3 discussion points
... when you press enter in this navigation treeview, what
should happen?
... it moves focus to the heading in the content area
ZoeBijl: the section has a different aria-label than the heading content
<Jemma> "In a real web page this region would typically be identified by a main landmark, but since this example already has a main landmark, this section is identified using the region landmark."
ZoeBijl: should this be a main instead of a section?
jongund: there's a comment in the code that says that if this was a real nav, this would be a main element
mck: it is nice when the main is labelled by the heading
jongund: use aria-labelledby with 2 ids - h1 and section label
ZoeBijl: for the focusing, then, would it make more sense to focus on the section?
mck: we did screen reader studies, I had it focusing on the sections, and when we changed it to focus on the heading, we had strong positive feedback
sarah_higley: a couple of things
lead me to think that focusing the section is a better user
experience
... you can have content before the heading, like close button,
etc
... focusing on a heading doesn't reliably read the heading
content in some screen readers unless you add an
aria-label[ledby]
mck: sarah, please chime in with Sina in the PR https://github.com/w3c/aria-practices/pull/1558
<Jemma> Actually, I am very intersted in the answer to Jon's question.
mck: in this treeview example, if
you arrow to About and press enter, it opens the about
page
... but if you go to the disclosure example, if you type enter
it opens a menu, not the page
sarah_higley: so full circle to split buttons ;)
mck: separate button
sarah_higley: do we want a new
example, or an option on the current example?
... Actually, I think a separate page, because the html would
be different - not just the js
... or multiple examples on the same page?
mck: no, we're trying to move
away from that so that it's easier to reference a specific
example
... it makes the example page more complicated, and harder to
understand
carmacleod: also, people don't always know that there's another example, because they don't scroll down
<scribe> chair: Matt King
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 Jemma carmacleod ZoeBijl MarkMccarthy sarah_higley jongund CurtBellew Regrets: Bryan Found Scribe: carmacleod Inferring ScribeNick: carmacleod 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: 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]