– DRAFT –
ARIA Authoring Practices Task Force

<Jemma> https://github.com/w3c/aria-practices/wiki/June-8%2C-2021-Agenda

APG redesign project update

<Jemma> APG redesign repo was set up and add various report and design mock up

<Jemma> we can talk about the update at next meeting

<Jemma> https://github.com/w3c/apg-redesign

<Jemma> issac: wireframes does not include new features yet. Info architecture will be the first step

Jump Tp

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

MK: The main issue is that it really works well for everyone by VO

<Jemma> Matt's concern - https://github.com/w3c/aria-practices/pull/1923#pullrequestreview-673670353

MK: It kind of works with Chrome if you use pass through key

MK: If we are going to model it, we don't want to leave some people out

MK: Suggest using JS for creating a hot key

MK: There maybe conflicts with examples, or other artifacts

SH: We had a discussion, that accesskeys aren't great, users are not familiar with accesskeys, scripting makes it more consistent

Siri: If you use a modifier...

MK: We will definitely use a modifier

MK: We could use ALT+zero, not super intuitive, but ALT is used for accesskeys in Chrome

JG: Accesskey information is announced by screen readers

MK: Does the screen reader add it to the label

SH: It is not to do with authoring

Siri: It automatically adds the shortcut key

<siri> +1 sarah

MK: I am not sure who is doing it, we have aria-hotkey, but that doesn't work with VO either

SH: We could add shortkey to the button label

JG: We already have the tooltip and we could add back in the aria-describedby

MK: It could get rid of the tooltip if it was in the menu button label

MK: We have some examples that were not looking at modifier keys

MK: We could make a terst for that

MK: It is on a list that we could test, that do not have a corresponding item in the keyboard table

MK: We will script ALT+0 and include the Keyboard assignment in the name of the button

MK: It is a button

JK: Status of review of the example, done with my review, we need other reviews

JK: When I use Jump To click it does not focus the the target

MK: You want a keyboard focus ring on the target item

JK: When you use the keyboard you get a focus ring and with the mouse no focus ring

MK: You are talking about after you click

MK: You can't tell you navigate to the item

Siri: If you have a skip link it doesn't show focus

JK: I don't understand

Siri: When the focus is shown on the main element, it is not interactive

JK: The sighted user gets different experience using the mouse and the keyboard

MK: I am curious about this the visual experience

JK: The keyboard way it works as I expected

JG: Functionally it still works the same with the mouse and the keyboard, the only difference us the focus highlight

JG: I will look at why the focus ring does not show with the mouse

HTML Range Slider Example

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

<Jemma> HTML Temperature Slider PR #1757

JG: We need reviewers

MK: We need to have reviewers assigned

JG: Example is ready for review
… assigning reviewers ..

JG: The JS is short, but the CSS is more complicated

MK: In this case, I am still kind of torn about keyboard documentation

<Jemma> https://raw.githack.com/w3c/aria-practices/range-thermostat/examples/slider/range-temperature.html

JG: I put keyboard support under accessibility features

MK: I wonder to stay with our template, and go ahead and document it, but say the keyboard support is provided by the browser

<Jemma> Keyboard support for the temperature control is provided by the native keyboard support for the input[type="range"] element (i.e. Up/Down Arrow, Page Up/Down, Home and End keys).

MK: Is page up and page down different on browsers?

JG: probably

MK: I am curious what the difference is between chrome and safari browsers

MK: I think we should document it

MK: From a functional review to do? We can't change the function of the browser, so we are testing is the changing the valuetext

JG: SHould I put the keyboard table back in?

MK: Yes, but I will make some edits

<Jemma> https://github.com/w3c/aria-practices/wiki/Pull-Request-Review-Process#functional_review

<Jemma> Functional review

<Jemma> Exercise the example with keyboard, mouse, and touch in Chrome, Firefox, and Safari to ensure:

<Jemma> Keyboard behaviors match the pattern documentation.

<Jemma> Mouse and touch behaviors match expected norms.

MK: We don't have any keyboard events

JG: The browser change evant it is not triggered by key down events

<siri> diff between browser chg event and keyboard chg event?

MK: So when you press the arrows the value doesn't change?

SH: The input event may fire on keyboard events

SH: Look on the input event

MK: Who's spec is that?

<Jemma> this is the code sarah mentioned,

<Jemma> this.rangeNode.addEventListener('keydown', this.onRangeChange.bind(this));

SH: Good question, I am not sure where it is

<Jemma> this.rangeNode.addEventListener('change', this.onRangeChange.bind(this));

SH: There is change events differ on input controls, text input they are pretty much the same, when they are different change occurs less than input event

MK: JG please try input event

SH: I will not say input is more consistent between browser

MK: We need to test on all three platform

BG: It might work on iOS

BG: Is it in the APG right now?

https://raw.githack.com/w3c/aria-practices/range-thermostat/examples/slider/range-temperature.html

BG: I need to build one soon

JG: I need to make changes to it

MK: There is a fair amount of functional review, and I will test with iOS

JG: I will try to test on all the platforms, just curious

MK: What about high contrast?

JG: We have a focus ring around the thumb

SH: You have to guess by the position

MK: So it makes sense in making custom sliders, you can add more features

SH: The track is tiny and hard to use the mouse with

SH: If you use the pseudo properties, you cannot style the background color of the rail

<Jemma> https://www.a11ywithlindsey.com/blog/creating-accessible-range-slider-css

MK: It is easy to add a range input, but difficult to style

Unicode Symbols in CSS Generated Content

<Jemma> https://www.w3.org/WAI/GL/wiki/Unicode_Character_with_an_On-Screen_Text_Alternative

JK: According to WCAG it is not recommended to use unicode

JK: Practical issue is up and down arrow, for indicating collapsed and expanded

MK: Is it something we want to show people how to make accessible

JK: I don't think we should unicode in HTML or CSS

MK: It is strictly a visual thing

<Jemma> Description

<Jemma> The objective of this technique is to show how to provide a visible, text alternative for an Unicode character that conveys information.

<Jemma> Some versions of assistive technologies will announce CSS generated content, as well as specific Unicode characters. However, because the announcement may be inaccurate aria-hidden="true" is used so it will be ignored by assistive technologies. An on-screen text alternative is added.

MK: CM was leaning toward this

MK: Any other comments on use of unicode?

Siri: You have to use aria-hidden if it is not useful

MK: Are we using aria-hidden, we are using css properties to make arrows

<Jemma> this is the code we are using

<Jemma> .disclosure-nav button::after {

<Jemma> content: "";

<Jemma> border-bottom: 1px solid #000;

<Jemma> border-right: 1px solid #000;

<Jemma> height: 0.5em;

<Jemma> margin-left: 0.75em;

<Jemma> width: 0.5em;

<Jemma> transform: rotate(45deg);

JG: We are currently using aria-hidden or using borders to generate arrows

MK: BG what is your thoughts on using unicode characters

BG: I don't recommend the use of unicode characters

MK: We don't want ATs to pick them up

MK: These are arrows to indicate state in menus

BG: We will override using accname techniques

BG: We also use aria-hidden

MK: You actually use unicode characters

BG: It is useful in some cases, but you need to prevent exposure

SH: Not a big fan of using aria-label to override, translation issues, use aria-hidden

SH: It looks like we are not using the aria-hidden