<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

Overall Status of 1.2 release 1

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

Wrap up Menu Button Improvements

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?

https://raw.githack.com/w3c/aria-practices/issue1399-menubutton-updates/examples/menu-button/menu-button-actions.html

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.

Slider Example Improvements

<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

Navigation tree view revisions

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

https://raw.githack.com/w3c/aria-practices/update-tree-nav/examples/treeview/treeview-navigation.html

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