scribe+

helen: you have to get sarcastic comments in

ACT standup

Helen: No update, planning to get to my rule. Thank you for feedback Dan, Giacomo

https://github.com/w3c/wcag-act-rules/pull/330

https://deploy-preview-330--wai-wcag-act-rules.netlify.app/standards-guidelines/act/rules/wcag/

Wilco: Working on an overview page for ACT rules shown with their WCAG criteria

Dan: Few PR reviews, addressing some comments. Got a review from Mike Gower
... Problems Mike identified were not new to the PR. Think that should go into another PR

Giacomo: I think the problem from the backlog TF, if we want to list the rule in the understanding document it will be okay for them.
... If it's already in the understanding document I agree. If not then they may not want it yet

Wilco: This is a proposed rule. Propose Dan opens a separate issue and leaves a comment about that in the PR.

Giacomo: opened a few issues, and reviewed some PRs.

Sasha: Reviewed automated acc support section PR from Carlos. Will fix some issues on a rule page

Shunguo: Updated the aria required owned rule. Small changes, sent it out for review

Vartika: Worked on some of the examples for aria state & properties

Filippo: Nothing to report

Chad: No updates

Helen: Shunguo suggested updating examples.

Shunguo: We made changes for ARIA 1.3. This rule has examples for combobox. The combobox requirements have changed in ARIA 1.3
... The first update is to align with ARIA 1.3, the others are some code cleanup

Helen: Should we go for ARIA editor's draft or latest working draft?

Shunguo: Daniel mentioned this a while back. ARIA is almost a live spec.

Helen: The reason I ask is that WCAG 3.0 isn't a rec yet, and people are already using its color contrast. Is this similar? Should we really use this?

<giacomo-petri> https://github.com/act-rules/act-rules.github.io/pull/2313

Giacomo: We've discussed this in the PR and agreed a while ago that we should remove it since it will be deprecated, and there is no support from AT.

+1

Giacomo: I don't see why we should remove it
... I agree with the first item, I think the others we should keep

Helen: I prefer we do this because AT don't support it, not because it's in an editor's draft

Wilco: Agree with Giacomo about picking up the first bullet, but not the others

Dan: Where does ARIA have a list of native semantics?

Shunguo: ARIA in HTML has a list
... The spec says that button has the implicit role of button and allows a few other roles.

https://www.w3.org/TR/html-aria/

Helen: Should we split this issue into two, or should we say point 2 and 3 is a point we can't agree on

Wilco: Suggest a vote, 1: address all 3 items, 2: Only address the first item

2

<giacomo-petri> 2

<Chadembox> 2

<sashanichols> 2

<Dan_Tripp> 2

<giacomo-petri> +1 to discard 2 and 3

<Helen> 2

Wilco: So we're only doing the first item, discard the others

Helen: The issue is that failed example 3, 4 and 5 pass the SC

Giacomo: Should we map 1.4.4 as a secondary requirement as being more strict?

Dan: Because there are multiple possible techniques, including adjusting font size, failing zoom but not failing font size is a pass

Jeremy: Dan and I discovered that they added that this is in the understanding document

Giacomo: It was always like this. W3C requires there is one way to do this.

Helen: If you have to manually override the operating system setting I don't think that's the intent of the SC.

Giacomo: if you use a chrome extension, zooming can change the default font size set by the author
... Firefox allows you to only change the text size

Helen: The update is not operating system but user agent
... Mobile apps get this from the operating system

Wilco: I can't express how much I hate this

Jeremy: I agree, we see a lot of sites that have absolute font sizes. They all now get to pass

Dan: This is where the secondary requirement potentially comes in
... It seems like just to keep it up with WCAG only failed example 3 needs to change

<Dan_Tripp> scribe+

<Dan_Tripp> Wilco: yes browsers still allow adjust font independent of zoom. largely hidden feature. yes, in theory this is maybe a pass (i.e. one technique only).

<Dan_Tripp> ... should not consider it an a11y-supported way b/c of how obscure it is.

<Dan_Tripp> ... if clipping occurs when page is resized through mainstream zoom, that should fail.

<Dan_Tripp> ... even if there is no failure on resize text.

<Dan_Tripp> Jeremy: different from my stance. yes.

<Dan_Tripp> ... more often I see: text-only fails and browser zoom passes.

<Dan_Tripp> Wilco: it's worse than that. new language is saying you can support either one. so if you happen to pass by text-only resizing, that's is allegedly ok. I think zoom resizing should be mandatory.

<Dan_Tripp> Helen: originally there was only text resize. then browser zoom came later.

<Dan_Tripp> ack

Giacomo: I agree that just one is required, but potentially in firefox text view only is more visible then other browsers. Users will usually zoom the entire page.
... At the same time I understand what AG is less strict, there are other ways to do this. Potentially, if you're just familiar with zoom, something might not work and you might not know how to address this.

Helen: I think secondary is a good idea. If you stick with 1.4.4 they technically pass but users cannot read the content
... we know that not having any form to zoom should be seen as a passable item.

Wilco: I don't like doing secondary. That is not what secondary requirements were intended to do

Helen: user agents must allow the ability to zoom

<Chadembox> Level Access and Allyant both test both

Dan: It seems the most common pattern when you test both methods is passing zoom but failing text resize is the most common

Jeremy: When it fails one method but not the other we raise it as a best practice

<Chadembox> +1

<Chadembox> We create issues for both

Dan: I think the scenario of failing zoom but passing text resize is rare

<Vartika> We raise the issue when it fails browser zoom. If it passes browser zoom, we do not raise the issue, as the most used method(Browser Zoom) helps us pass WCAG 1.4.4 more confidently.

<Chadembox> More time on that one +1

Helen: I think we'll have to get back to this at a later point

This is scribe.perl Revision VERSION of 2020-12-31
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: Helen, giacomo-petri, Dan_Tripp, Wilco, sashanichols, filippo-zorzi, Jeremy
Present: Helen, giacomo-petri, Dan_Tripp, Wilco, sashanichols, filippo-zorzi, Jeremy
No ScribeNick specified.  Guessing ScribeNick: Wilco
Inferring Scribes: Wilco

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