<CarlosD> scribe: Helen
Carlos: only 1 item up for review
that is ready to be merged and we don't have anything in 2
weeks view but I guess we have several PRs that can go into
call for review?
... Jean-Yves we have about 5 from you, and a few from
Wilco
Wilco: I m going to hold off on
Helen's PR changes as changes a good number of rules...
... No it can go in as mine is more problematic
... they have not approved my current version yet
<CarlosD> https://github.com/act-rules/act-rules.github.io/issues/assigned/carlosapaduarte
Carlos: There are a couple of my
issues here - I opened a PR yesterday which is 1764 that
updates the programmatic def
... if you guys can preview that it would be great
... I got your feedback Wilco on my update of data, and I
replied to ti
Wilco: I missed the reply
Carlos: It relates to keyboard focusable, that are elements that are visible or not visible
Wilco: Can we talk about it as an agenda item?
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/assigned/WilcoFiers
Wilco: My assigned issues: for my
part I am working on migration stuff that is going slower than
I want to. Waiting on AO to approve it as migration
related
... we are planning to move it all over to the W3C website with
implementation data, going through an iterative process to get
it approved. It is taking a longer time than I would like but
it is moving forward
... also working on an update to change the implementation
status
<Wilco> https://github.com/w3c/wcag-act/pull/522/files
Wilco: it will be added to these
files
... I'm hoping to have that done this week
<CarlosD> https://github.com/act-rules/act-rules.github.io/issues/assigned/Jym77
Jean-Yves: I am working on my items and I have pull requests open, so am working on them all
<CarlosD> https://github.com/act-rules/act-rules.github.io/issues/assigned/daniel-montalvo
Daniel: I have not touched the
old rule as not sure. I am also working on the accessible name
issue in PR - adding in samples 1760. WIP as working on Wilco's
requests. and the tests are still failing.
... would like a review of that
Carlo: Anne you have none so please take up some
Carlos: Helen - yours should be
closed soon!
... Tom please feel free to pick some work up as we monitor and
help as needed
Wilco: we are going through the AG rules - we are going through the common input aspects document. The last thing we are doing is going through the approved updates that we want to see on the website
Carlos: You have 3 approvals on the PR, and what is the status now?
Jean-Yves: We are checking it as
it is semantically correct, and we want to link it to a precise
condition
... looks like people do not disagree so I clean up the
PR
... I will try to not do it all at once as it is a large piece
of work
Wilco: The tests are failing and I don't think the way the website currently works it won't work
Jean-Yves: yes the tests are failing and that is the biggest problem, but the new website should work with this so wait for the migration?
Wilco: Yeah so the script is assuming every internal link points to a heading or an internal definition
Jean-Yves: Absolutely, that is something I can amend
Wilco: The approvals have 2 from
the same company, so do we need a 4th?
... Helen - if Kren has approved something please do not do
that as you work in the same company
Helen: Will do and will let Karen know
<Wilco> <dfn id="in-body">**(in body)**</dfn>
Wilco: Are we happy with this
formulation?
... I always prefer the colon and no brackets, and not make it
bold using stars but use the stylesheet
<Wilco> <dfn id="in-body">in body</dfn>:
Carlos: Add the suggestion
please?>
... that is easier to write and the CSS can handle the rest
Jean-Yves: yes
Carlos: I'm happy with that proposal but update the test before asking for a new review
Jean-Yves: Yes it is ongoing a bit but yes no problem
Wilco: I have another point... There is a risk here of collisions of ids with existing defintions
Jean-Yves: That is why I am making them different to make sure we have no conflicts, so we must check with uniqueness per file
Wilco: If we fail a lang
definition we would suddenly have a conflict with this
rule
... we could pre reference them with dfn?
Jean-Yves: Or we have a 6 digit id?
Wilco: YES that is perfect and makes it unique
Carlos: Just to make sure what you are proposing is?
<CarlosD> <dfn id="off6ek-in-body">in body</dfn>:
Carlos: This is the current proposal right?
Jean-Yves: yes it is
<CarlosD> https://github.com/act-rules/act-rules.github.io/pull/1444
Carlos: So this old and ancient
PR tries to handle 2 situations for aria-hidden
... it is the aria-hidden focus rule that will stop scripts
from focusing items, or not in the sequential order but can be
focused by click or touch events
... the proposal from Wilco is creating a new focusable
condition, if one of the following are true, if it is in the
sequential order or if they are focused with a click
event
... and you disagreed with the click event as anything with a
tabindex can be focusable
... and to change the keyboard focusable
Wilco: I want to suggest we take it in a different direction to stop it going in the original direction
<Wilco> https://github.com/dequelabs/axe-core/issues/3300#issuecomment-977330704
Wilco: There are several AT that
will allow you to focus items not in the sequential order or
with click events. But it is a bit controversial and I have to
explain to others and here is an example of an argument with 2
MS employees
... Should be anything that is focusable
... like a tabindex or something like that
Jean-Yves: we always have issues
with defining what is focusable
... but sequential order is easier to define
... the rule is not complete but need to think of a sub rule
that explains the edge cases you just described
... The idea of splitting it up so we can come back to it and
work on it
Helen: Yes browser and AT issues can cause issues here that might be bugs
Wilco: We can capture the items
that follow the spec and should be focusable as it is in the
spec
... It goes beyond what we currently do but not by much
Carlos: It solves some of the
issues, but not all, like the focus not being changed in x
milliseconds
... would you guys be ok with that?
Daniel: I think we should cover what is in the spec, but what if we have an item that is mouse or touch focusable but not keyboard focusable?
Wilco: I don't think those would be affected by the rules we are looking at here as that is about keyboard focus
Daniel: I was just broadening the scope to make sure we consider this case
carlos: so the current proposal
is to add to the current defintion and to add the tabindex and
that the focus is not taken away
... Anne - what are your thoughts?
Anne: I do not understand enough to have an informed opinion but nothing sounds off to me
Tom: ditto to Anne's comment
Carlos: I will follow this
direction - I will follow the rules and see if they are
affected by this change and see if any rules are impacted by
this definition and change any that are
... we have 9 minutes left - I will have a look at what we can
address...
Carlos: This was raised more than a year ago about visible labels
Wilco: the concern here was that
we are not checking things: as in we are checking the text
exists but not the order as we do not know by looking at the
DOM
... for all we know the order can be different from how the
text appears visually so this can cause the tests to fail
Carlos: Don't we have an assumption about that?
Wilco: It is not covered as it is hard to define
Carlos: No we just have thm about resources not loading
Wilco: We could add it to the background
Anne: It could be a false positive if you add more words into the middle
Tom: Isn't the rule about it must start with the text.
Anne: Yes the rule tries to check that but it cannot define the order
Jean-Yves: Yes the order is hard
to calculate so we just check the text is there
... It is a best practice to have it first it just has to be
there
Wilco: It is a failure of the
WCAG rule to be in the wrong order, but not the ACT rule
... The reason this was logged as an example had specific items
that are shown in different areas of the page, and additional
information added to the label. So the visible text passed, but
the added hidden text fails it
... We didn't require the text be concatenated as that was the
original rule of the component
Jean-Yves: Looking at the rule it seems to be a failing technique that is not written
Anne: Yes so the accessible name should be visible?
Jean-Yves: So the accessible name has text added in the middle making it a failure
Carlos: Let's address this another time after we have time to review it
Tom: I am happy to be here
Anne: My favourite time slot is here and should stay
Jean-Yves: Welcome Tom and thanks everyone
Daniel: Welcome Tom
Helen: Welcome Tom
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, CarlosD, Wilco, Jean-Yves Present: Helen, CarlosD, Wilco, Jean-Yves Found Scribe: Helen Inferring ScribeNick: Helen 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.)[End of scribe.perl diagnostic output]