ACT Standup

Wilco, spent time on version numbers

<Wilco> scribe: Will_c

Daniel - Not much, working on publications, and publication dates will now be tuesdays

Helen - Working on manual rule. It's an action rule, so need to do more work, more thought. Dan is helping me out with it. I will be reaching out to everyone who has offered to help with validating manual rules

Helen - lots of theorizing this week

Kathy - add me to that list

Catherine - Been doing pull requests.

Trevor: I didn't have a lot of time. Mainly got to going through open pull requests. Some discussions
... trapped inside a guitar

Tom: Not a whole lot done. trying to make progress on aria rules.

Kathy: Haven't had much time this week either. One of the agenda items is for me.

Chris: Reviewed 'heading has non empty accessible name"
... At a loss for the actual update needed from notes. Need to sync up with Kathy and Wilco.

Wilco: This is an agenda item, so no worries

Will: I didn't do much either

Iframe has name rule, discussion

Wilco: iFrame has non-empty accesible name
... Summary - generally fairly accepted iFrames need accessible name. Not entirely clear why, though
... two reasons to do it. Firefox - puts focus on iFrames. others do not.
... 2nd reason - Safari w/ voiceOver. Any iFrame without none or presentation, it's treated like a new application you must enter into
... these are the two problems for iFrames without a name.

Will: I think it's important.

Wilco: JAWS has a 'frames list'. it will show up as blank iframe

<ChrisLoiselle> Frame in JAWS : List Frames INSERT+F9

Helen: In my experience many adverts in iFrames

Daniel: Lots of users like being able to skip ads.
... Twitter uses iFrames, I think. and you get bad names.

Wilco: Sounds like same page. Not a bad idea still to have it
... Should you fail iFrames for chrome and edge?

group: banter

Kathy: What about JAWS and edge? Does it give the info? or still blank?
... So if it's still blank, they can still navigate with iFrames list.

Wilco: put aside firefox and safari and just edge and chrome.

Chris: if screenreader can navigate to it but it has no name, that's troublesome. I would want it to describe the iframe.

Wilco: I mean, is this a failure of WCAG?
... lists and tables don't require a name, so why does an iFrame?

Helen: names for everything

Wilco: there is difficulty around safari. Safari has never supported aria-labels on iframes. only title.

Helen: Firefox uses a different engine

Wilco: Firefox requires a name whether it has role="none" on it b/c it's still focusable
... very unusual.
... How do we capture these two realities on this rule?

<ChrisLoiselle> https://www.w3.org/WAI/WCAG21/Techniques/html/H64.html

Tom: There is a wcag tecnique in 2.4.1 for names for frames

Chris: h64 - title in iFrame.
... When role=none is on element, that means it's not mean to be interacted with?

Wilco: Safari skips iFrames without content, but i don't think Firefox does

Kathy: what are browsers supposed to do?

Wilco: this is explicitly left to the browsers

Helen: Would this be a case of background/accessibility limitations?
... Trying to code for variations can change
... easier to think of mainstream tests

Wilco: That is sort of the approach we took last time. But the thing we end up requiring is sort of ambiguous. doesn't cover either of the major cases and only addresses the frames without names

Helen: What is the solution?

Tom: Browser specific rules forces testers to run multiple tests on multiple browsers

Chris: if we wanted a rule spanning user agents, would it be worthwhile to flag the user agent and the failure?

Helen: Which browser is at fault?

Catherine: testing-wise, coding-wise, we don't want to code to specific screenreader, I think that's the same for browsers
... I feel like iFrames should be named, but if tables aren't, why should iFrames? I'm of two minds

Helen: Tables can contextually be named by headings and captions, iframes can't

Trevor: One rule for all is basic, but weird if it doesn't make accessibility issues?
... Feels like we are stuck by our own rules.

<ChrisLoiselle> https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element

Wilco: Maybe we have another solution - how about we go LCD - write the rule in such a way that if it fails in BOTH FF and safari, then it's a failure. But if it works on one, then it's good

Tom: It should have a defined tabindex, maybe. Because it doesn't need a name if it isn't focusable.

Wilco: Tabindex doesn't stop the focus. It does literally nothing to the behavior in browsers.

Tom: I will try again. Thought it DID stop focus

Wilco: THe 'fails both' is a standard that could work

Will: brb

Helen: will ghosted

<thbrunet> https://z6oei.csb.app/

Tom: Tabindex DOES go to the frame in chrome

Dan: is it different between OS?

Wilco: that happens because there is nothing focusable INSIDE. CHrome automatically moves inside

Tom: Confirmed

Wilco: Firefox doesn't care about role="none"
... 'iFrames need an accessible name unless they have negative tabindex or role=presentation or role=none

<trevor> +1

Wilco: this pushes browser specific issues to the acc support section

<Helen> +1

<kathy> +1

+1

Kathy: I think we have to update trusted tester for the role presentation/none
... Tried to kick it to ACT.

<thbrunet> +1

<Catherine_Droege> +1

<ChrisLoiselle> this is what Mozilla has, for reference https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#accessibility_concerns

Wilco: Tom, are you the liason on it?

<ChrisLoiselle> +1

Tom: I'll take it

Kathy: one Q about conflict resolution about role=none on interactive element

Wilco: We need to steer clear of it.
... we can't use semantic role definintion. we have to be explicit

Helen: Do all the browsers trreat iframes poorly so we will get rid of them?

Label in name rule, discussion

Wilco: Labels! huzzah!

Kathy: We have a rule for 2.5.3 - label in name. Name contains text that is presented visually

<kathy> https://github.com/w3c/wcag/issues/1936

Kathy: big discussion is about spaces in the accessible name that don't match up with visible label, particularly for numbers, is that ok? How strict is the matching?
... dates abck to june 2021, much discussion is based on how speech recognition is affected by spaces
... example, is it okay to have a year as "20 23" or "2023"?
... if someone says it visually like '20 23' will it not get that they mean '2023'. IE: no one says 'nieteen thousand nine hundred and ninety nine' for 1999

Will: have we done testing on these examples?

<Wilco> https://github.com/act-rules/act-rules.github.io/issues/1615#issuecomment-858800969

<kathy> https://github.com/act-rules/act-rules.github.io/issues/1615#issuecomment-858800969

Kathy: There is a lot of informaiton from sc testing
... There are some differences. SOme can compare the visible v accessible, some cant

Wilco: two problems here. First an accessibility support question. 2 of the 3 dictation programs can use the visible label
... The only one that didn't do it was voice control.

Helen: not just vc, hear them saying to visually see, and that they have to grid it out
... 2.5.3 is so important to stop this issue happening

Wilco: We should deal with the support question first
... One of these programs doesn't pick up the visible text. So it's only a problem in one of these programs
... Does that fail at all, because it's a lack of support, not the app?
... If we have rules that only fail specific tech, we should make the requirements secondary requirements. What you support may vary.
... This allows testers to say it's a problem but I don't fail

Kathy: Trusted Tester doesn't cover, so I don't have any examples
... If the assistive tech is able to look thevisible label, that's nice, but that's not what the requirement is about

Trevor: understanding doc says 'match or contain'.

Wilco: Tools know common speech patterns. It knows we break up speech patterns like that, like "wuhcag' vs 'W C A G'
... My take is spacing has to match. You cannot add spaces

Helen: When companies have names that don't get pronounced correctly and they change it behind the scenes, that doesn't work?

Wilco: Yep, it spaces out in braille too, so don't do it

We are at time

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)

Present: kathy, Helen, Wilco, trevor, thbrunet, Catherine_Droege, ChrisLoiselle
Found Scribe: Will_c
Inferring ScribeNick: Will_C

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


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: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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