W3C

– DRAFT –
ARIAAuthoring Practices Task Force

01 March 2022

Attendees

Present
CurtBellew, isaacdurazo, JaeunJemmaKu, jongund, Matt_King, Rich_Noah
Regrets
-
Chair
Jemma
Scribe
Rich_Noah

Meeting minutes

<Jem> rragent, make log public

<Jem> Meeting Title: ARIA Authoring Practice Guide

set up and review agenda

Jem: other wg is talking about changing times for daylight savings time

jamesn: we have a couple more weeks

APG issue triage

<Jem> https://github.com/w3c/aria-practices/issues?q=is%3Aissue+is%3Aopen+created%3A%3E2021-10-15+no%3Alabel+

<Jem> https://github.com/w3c/aria-practices/issues/2248

Matt_King: we just updated the navigation bar and hope they see the latest

Jem: Zoe asked to review issue tracker for Jaws

<Jem> It is a JAWS bug: FreedomScientific/VFO-standards-support#415

Jem: we can close this issue

Matt_King: we have a tag for not for practices, that is the one we want.

Jem: issue is closed

<Jem> https://github.com/w3c/aria-practices/issues/2247

jem: jon this is related to the tabs issue

Matt_King: maybe we should add this as an agenda item as it requires discussion

<Jem> https://github.com/w3c/aria-practices/issues/2245

Jem: they are looking at 1.1 again

Matt_King: we did not change this note, it is still the same

Matt_King: I think this is actually editorial. Assign it to me, add the editorial tag and add it to the list box project

Jem: done

https://github.com/w3c/aria-practices/issues/2247

Matt_King: we add an agenda item tag

https://github.com/w3c/aria-practices/issues/2063

Matt_King: we talked about this one and agreed to add some agenda time. Add it to the grid project.

Matt_King: there is a little bit of research to do here.

Open PR

<Jem> https://github.com/w3c/aria-practices/pull/2194

Matt_King: jon, I think you responded to a couple comments. I am still trying to figure out what to write.

jongunderson: updating to accurately indicate what is happening.

Matt_King: I was trying to figure out if the issue of transparency was relevant here.

jongunderson: it does, i am using border with rounding on the corners to make it look nicer. I can use outline but we use borders in other examples.

Matt_King: need to make sure the accessibility documentation is clear and consistent with what is used in other places. I will update with any questions.

jongunderson: I did not make any code changes based on Zoe's comments.

Matt_King: I will make an update to content for clarity.

Matt_King: we are really close to merging.

Jem: if you can add that comment

jamesn: i will add comment and screenshot

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

Matt_King: Jemma it looks like you and me. Looks like a problem with conflicting files.

APG site redesign discussion

<isaacdurazo> https://github.com/w3c/apg-redesign/issues/8

isaacdurazo: last week we shared the redesign and got some feedback.

isaacdurazo: we talked about some changes with the resource area and I updated the mockup.

isaacdurazo: now that we have a good sense of the type of content and also updated the illustration. I also sent to Matt and Jemma the current character/word ranges for the different content areas.

<Jem> I am sharing the updated mock up by zoom screen sharing

Matt_King: the cards on other pages are just automatic extracts. For these sections, i.e. landmarks and patterns, I am hoping there will be some type of automatic excerpt.

Matt_King: I would like to start out with heading and the words that appear that with the words are automatically extracted with the read more link.

Matt_King: I am pretty sure we don't to hand code those sections.

isaacdurazo: We have that current functionality and can see doing that here.

Matt_King: the word counts are really helpful. I wonder what format or file we want to start experimenting with the constraints.

isaacdurazo: Matt will you be writing the initial copy

Matt_King: will need to chat about what format to use.

Jem: do you have any other questions?

isaacdurazo: we have received comments regarding accessibility when implementing.

Jem: that is great considering it in the design phase.

Jem: is this file how we should interact with it?

isaacdurazo: yes

focusability of disabled control

<Jem> https://github.com/w3c/aria-practices/issues/2176

jamesn: before we talk about. If a disable control becomes focusable does it have to meet the 4.5:1 ratio, the text.

jamesn: if you focus is it disabled anymore?

Matt_King: you can have something disabled but focusable.

jamesn: in my opinion as long as you put focus on it is no longer an inactive component and has to meet the 4.5:1 contrast ratio.

Matt_King: that is a reasonable interpretation. Part of me wonders why not focused or not focusable would meet the description. Why does focus change it?

<jamesn> https://www.w3.org/TR/WCAG21/#contrast-minimum

jamesn: if you meet the 4.5:1 ratio it doesn't look inactive anymore. Per WCAG you need to make it meet the 4.5:1 ratio.

<siri> Inactive User Interface Components User Interface Components that are not available for user interaction (e.g., a disabled control in HTML) are not required to meet contrast requirements in WCAG 2.1. An inactive user interface component is visible but not currently operable. An example would be a submit button at the bottom of a form that is visible but cannot be activated until all the required fields in the form are completed. Grey button with n[CUT]

Matt_King: you would need have a different way to show that.

jamesn: there is a fundamental problem with controls and I do not know how to solve it.

Matt_King: i am particularly concerned about high contrast mode and gray scaling

jamesn: you can specify GrayText in high contrast

<siri> Inactive components, such as disabled controls in HTML, are not available for user interaction. The decision to exempt inactive controls from the contrast requirements was based on a number of considerations. Although it would be benefitial to some people to discern inactive controls, a one-size-fits-all solution has been very difficult to establish. A method of varying the presentation of disabled controls, such as adding an icon for disabled cont[CUT]

<siri> https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

Matt_King: my guidance has been that by default we should focus disabled things unless there is a clear reason to.

Matt_King: we have had a hard time finding a sighted keyboard user that is dependent solely on a keyboard.

<Jem> three options for disabled with focus

<Jem> 1. let them have low perceivablity

<Jem> "User Interface Components that are not available for user interaction (e.g., a disabled control in HTML) are not required to meet contrast requirements in WCAG 2.1. An inactive user interface component is visible but not currently operable. An example would be a submit button at the bottom of a form that is visible but cannot be activated until all the required fields in the form are completed."

<Jem> https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

<Jem> "Inactive components, such as disabled controls in HTML, are not available for user interaction. The decision to exempt inactive controls from the contrast requirements was based on a number of considerations. Although it would be benefitial to some people to discern inactive controls, a one-size-fits-all solution has been very difficult to establish. A method of varying the presentation of disabled controls, such as adding an icon for

<Jem> disabled controls, based on user preferences is anticipated as an advancement in the future."

<Jem> what APG can do this clearly spell out trade off

<Jem> and suggest options to the users of APG.

<Jem> we can also ask clarification to WCAG group

<Jem> mck: I ran into muliple challeges of defining the keyboard users.

<Jem> in a narrow way.

<Jem> ... small group formation?

<Matt_King> To summarize, there are multiple options for authors. The group is considering improving APG by spelling out options and identifying the tradeoffs among them.

<Matt_King> Options:

<Matt_King> 1. Current default in HTML: disabled controls are hard to perceive due to low contrast and they are not focusable.

<Matt_King> 2. Enable focusability of disabled controls while still leaving them hard to perceive with low contrast. The low contrast makes their disabled state perceivable, but some interpretations of WCAG may call this out as a problem because some people may say that a focusable control is active even if it is not operable.

<Matt_King> 3. Use low contrast to indicate a disabled state when controls are not focused but make them easy to perceive when focused and use an alternative focus indicator that clearly communicates that the control is not operable.

<Matt_King> 4. Do not use low contrast to indicate a disabled state. Use some other type of persistent indicator. Ensure that indicator is separately perceivable from focus so that a disabled control can be focused and easily perceived as disabled.

<Matt_King> The APG could propose various designs for options 3 and 4 and delineate the tradeoffs when compared to options 1 and 2. The APG might recommend specific options for specific scenarios. One of the common scenarios discussed is a calendar grid with certain dates or ranges of dates that are disabled.

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).

Diagnostics

Succeeded: s/gray text/GrayText/

Maybe present: jamesn, Jem, jongunderson