<CarlosD> scribe+ dan_tripp

/invite zakim #wcag-act

testing

Call for review https://github.com/act-rules/act-rules.github.io/issues/461

carlos: nothing in 1-week call for review. in 2-week call for review: 1 from giacomo.
... carlos will leave comments in PR re: failing tests.

Assigned issues https://github.com/act-rules/act-rules.github.io/issues?page=1&q=is%3Aissue+is%3Aopen

carlos: waiting for a couple of reviews. PRs 1845. 1560. jean-yves is also: PRs 1994 1923.
... please everyone review the above if you can.

todd: re: PR 1926 - still discussing that one?

carlos: no, you can issue the call for review.

todd: no, it doesn't need the call for review.

carlos: yes, it does, because you updated examples. it needs a 2-week call for review.
... will do.

XXX ^^ todd: will do.

!zak

Update from the ACT Task Force https://github.com/w3c/wcag-act/pull/522/files

carlos: todd, what has the task force been up to?

todd: haven't been. asking helen would be better.

carlos: helen is away for a minute. let's wait.

wilco: from task force: planning to deprecate the empty heading rule.
... wants to note it here, so if there are any concerns, task force will know.
... re: parsing 4.1.1, on hold until they have an answer from AGWG.

helen: we have an ongoing discussion on task force re: visible name matching accessible name.
... re: punctuation, exact matching. hypen suggestion was "tutted" (?)
... number cases also discussed.

giacomo: PR 1907 should be merged, yes.

carlos: it's still failing tests. go to checks. follow link at bottom of conversation. there you have message saying checks were not successful. there's a details link on that line. will bring you to tests that were failing.

giacomo: [sees glossary tab etc.] I'll fix it.
... I'll send you [carlos] an email.

Update from Manual Test Rules subgroups https://github.com/act-rules/act-rules.github.io/issues/1952

helen: I emailed CG and TF. asking for help w/ manual rules.
... 1 person from TF will, in a few weeks, help.
... checked on current rules, which ones not covered by current tests.
... difficulty: hard to define, create examples.
... once I get 3-4 people I'll create a sub-group call.

<CarlosD> scribe+ CarlosD

<CarlosD> dan_tripp: the test is working on my machine, but I'm not sure how you can make it run

<CarlosD> ... I'll be able to help you getting it to run

<Helen_B> https://github.com/act-rules/act-rules.github.io/pull/2022

<CarlosD> dan: the issue is from the use of test-assets

<CarlosD> CarlosD: the best way is to update the path to the location where the test-assets are in the user machine

<CarlosD> Wilco: You may set up a codepen

<CarlosD> dan_tripp: I'll do that and set up a page where the example can be checked without the need to set up anything

<CarlosD> Helen_B: When that is ready I'll get back to work on the rule

Autoplay rule [x0paj4] failed examples don't autoplay in major browsers https://github.com/act-rules/act-rules.github.io/issues/2030

giacomo: maybe for non-technical people. axe-con and CSUN in the next month. opportunity to bring someone to the group.

carlos: browsers differ. example wouldn't fail b/c video wasn't auto-playing in some browsers.
... wilco raised this issue. it's on chromium browers. I did more tests. found similar behaviour on firefox and safari. i.e. couldn't get failed example to auto-play.
... so I created the issue. 2 potential ways to address this: 1) deprecate the rule.

jean-yves tests showed that video /sometimes/ auto-played. couldn't narrow down conditions. may depend on devtools being open, headset connected, opening from rule page vs. entering URL directly into address bar.

scribe: but either way the rule is valid even if video only auto-plays sometimes. so deprecating the rule isn't so good - would assume that browsers already fixed auto-play. but jean-yves shows that this isn't certain.
... so we could go w/ wilco's suggestion. change applicibility to users that play w/o user intervention.
... discinction between autoplay attribute vs. "automatically play" through script.
... browsers seem to ignore autoplay attribute. but not scripts which accomplish the same thing.

dan: change in applicibility is good.

carlos: I agree.

wilco: should the rule be scoped down to only audio?

carlos: browsers behave the same re: audio and video IIRC. so scoping down to audio doesn't solve the problem.

wilco: are we sure that a scripted auto-play does work?

carlos: can't be completely sure without trying it.

wilco: if browsers have gotten clever, then maybe they do prevent the scripted auto-play.

carlos: will do experiments re: browser behaviour on 1) auto-playing audio, and 2) scripted auto-play. then will update issue.

Should inert iframes with focusable content fail? https://github.com/act-rules/act-rules.github.io/issues/1965

carlos: last week we discussed updating our definition of sequential focus.

giacomo: assume that inert attribute means that no users can access iframe

carlos: applicability - w/ inert iframe, there is no focusable content.

giacomo: if you pick up iframe itself (i.e. src URL) then it will have focusable content. but embedded in another page it won't.
... maybe change applicability to exclude iframes w/ inert

wilco: agree
... also consider modals. implicit inert w/ no inert property.
... this is a case when the rule should be inapplicable and currently isn't.

carlos: this is about an iframe on the page outside the modal.

giacomo: we could update our definition of 'inert' to include such iframes outside modals.

wilco: agree.

carlos: agree.
... solution will be to update applicability, and update our definition of inert.

Consider case sensitivity in ARIA rules https://github.com/act-rules/act-rules.github.io/issues/1866

giacomo: issue / feedback from scott is still valid.

carlos: so browsers are not dealing w/ aria case-insensitively?

giacomo: correct.

carlos: if AT misses out due to case, will create a11y barrier.

giacomo: will need to check browser behaviour

carlos: we've learned that support is not coherent.

giacomo: just the fact that role="MAIN" (upper case) isn't working w/ eg. jaws/firefox - this indicates a problem.

carlos: agree. issue here is how we address it.

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: CarlosD, dan_tripp, Wilco, ToddL, Helen_B, giacomo-petri
Present: CarlosD, dan_tripp, Wilco, ToddL, Helen_B, giacomo-petri
No ScribeNick specified.  Guessing ScribeNick: dan_tripp
Inferring Scribes: dan_tripp

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