Minutes 2021 02 11 - act-rules/act-rules.github.io GitHub Wiki

Present: Emma, Aron, Wilco, Jean-Yves, Will, Anne, Dan Seagul, Daniel Montalvo, Susan, Carlos, Stanimira

Scribe: Susan

<Wilco_> https://github.com/act-rules/act-rules.github.io/pull/1522

wilco: asks for comments today on new rule 1.4.5

<Wilco_> https://github.com/act-rules/act-rules.github.io/issues/1120#issuecomment-585812132

wilco: look at rules ready for publican

Jean-Yves: issue 492 role attribute has been merged and ready for review

wilco: 493 from Carlos has no progress

Jean-yves: issue 490 not ready

wilco: won't have time this month issue 435 and 437,

jean-yves: 499, 507 not ready

wilco: label is part of accessible name is ready

wilco: header attr was reviewed today

wilco: link and menuitem are in progress, think we're good

wilco: mary jo mueller is stepping back as member and chair of ACT TG

wilco: result is task force is now another person short, was already too small before.

wilco: conversation about some of task force's work being moved over to community group is happening. unsure what that would look like.

wilco, shadi and carlos are working on proposal to bring to TF and community group, possibly by next meeting.

wilco: this does mean things might change about how community group does things

wilco: don't imagine all goals we have can be done as things currently operate

emma: asks how current task force is working

wilco: says shadi is the main person who brings to task force, explains how it is difficult to become invited member.

wilco: work of getting feedback back and forth to task force from community group is inefficient

wilco: current set up assumed other groups would also be doing work and that hasn't happened

Jean-yves: agrees it can be ineffcient but thinks there is value to current feedback loop, otherwise there is a risk of lack of input from community, fresh eyes add quality to rules

emma: agrees with JY but says TF brings another point of view as they're involved with WCAG as well

wilco: agrees and is leaning to having members of TF join the community group. but there is a lot more to work out. there is value to the second step of review and worth keeping

anne: how many people on TF?

wilco: 6 active inc Shadi & Daniel.

anne: only 3 or 4 people in TF who aren't in community group.

wilco: those people are open to joining c. group

wilco: inclined to have separate call inc TF with community group for 'final call' work

aron: autocomplete rule currently would fail number fields that have type-tel

aron: believe this wouldn't be a failure as 1.3.5 only requires presence of type attr

aron: assumption of 1.3.5 is that type is correct but was though it would be rare to have incorrect type

emma: this isn

emma: this isn't about verifying if the type is correct? that's a user agent bug

aron: spec says it must be correct type to allow succesful data entry but that's not the point of SC 1.3.5

aron: tested if you can still query with wrong type and it was fine

emma: is it possible to come up with example that doesn't have that bug?

aron: regardless whether or not input field is correctly filled out in chromium it works fine. just a firefox issue

aron: bottom line, you can still query property even if type is wrong and that is point of 1.3.5

wilco: colleague corrected me in saying autocomplete from browser is very useful for pwd which suggests it's not just querying value of ac field but how it functions in browser

wilco: reason for second expecation is that it works in the browser

wilco: if you put type tel on field that doesn't allow it, it's not going to work. it's not going to get auto-filled

wilco: that then adds to cognitive load

will: we test credit unions, autocomplete is very important to pwd if it's not done correctly

will: doesn't really understand what's being asked for? exemption for ios issue?

wilco: yes, generally should there be exemptions for user agent issues

will: with general exemption, this remains even if user agents fix it

anne: shouldn't this be in a11y support

aron: last time checked, it was in there. agrees that it is useful but is not WCAG requirement. wCAG only requires something that's programmatically determinable not correct

wilco: programmatically determinable isn't definable. we must decide that

wilco: we can decide if you create something browser can't understand it is not an exception

emma: is it failing the standard or is browser failing user

anne: clarification, is this about have AC and type tel? if you only have type tel on DOB but no AC, that doesn't have anything to do with this issue

wilco: correct

wilco: you are required to have ac on that

anne: doesn't matter if you have ac or type tel

wilco: 1.3.5 requires the autocomplete on such a field

anne: doesn't seem this adds anything useful for users in her country. wouldn't add any value.

anne: do we need to require for AC feature on type tel?

aron: if it's asking for telephone number, yes for AC. that is the requirement, not about the type

aron: thinks defintion of programmatically determinable is quite clear, something that computer can understand,

wilco: 'programmatically determined' needs to be part of understanding.

wilco: if html spec or aria spec defines this, if type=tel being correct is not in spec, it isn't programmatically determinable

wilco: calls for resolution

will: HTML takes priority over OS. otherwise we'd be approving hack

wilco: testing this is on his to do list

Jean-yves: depending on test, we can explain in background that this is common bad practice

aron: one more question, is anne askign to split this rule?

aron: anne please briefly explain suggestion

anne: implementation tests allows for this poor coding sometimes.

aron: rule fails it on assumption that form is taking user input

jean-yves: agree that we can have two rules one for following spec and one manual rule for verifying correct input type

emma: there are similar rules, check that somtthing has a value and then if it is correct

wilco, resolution to change rule to allow auto-complete off

jean-yves: yes as well as new rule that it is correct

wilco: and that second rule is not part of resolving this issue

anne: expectation 2 of that rule is that it's approrpriate

jean-yves: yes but that is not part of this rule

emma: that needs to be more clear

anne: maybe 'appropriate according to HTML spec'?

wilco: yes defintiions should understandable without memorizing

wilco: aron make sure that is captured in the issue

RESOLUTION: allow turn off auto complete

aron: TF has 2 points in feedback that I don't fully agree with

aron: first point, does not seem to be issue that header cells don't have assigned data cells. should be changed for data cells having assigned header cells

aron: assumption is that there are edge cases that some don't have them and rule is valid is.

aron: second Q, TF asked what 'assigned' means. think this is clear in rule and doesn't want to change

wilco: please comment on issue. am inclined to agree with aron

wilco: our own implementation allows header cells with no data cells, generally agrees

aron: could do this both ways. always going to be assumption made for this rule

jean-yves: easy to add applicability of element that is part of table that contains header and data cells, not tables with no data cells. would remove some of those edge cases

aron: agrees, not being empty should be added

wilco: leave comments in issue

daniel S: no final thoughts

Daniel M: looking forward to how we'll organize the group

anne: glad to be back, would like workshop on process of group/TF

aron: glad we clairfied two new rules

carlos: agrees with resolution

emma: good discussion. suggested to group she met that they should pay attention to AG because they are doing a11y work using AI.

wilco: would love to look into how to test for implementors that use AI

jean-yves: looking forward to newcomer workshop

stanimira: bit overwhelmed hope to catch up next time <EmmaJ_PR> group = Evinced