<dmontalvo> scribe: dmontalvo
Carlos: Nothing on CFR yet, but
some approved PRs.
... Good idea to wait for September for these to go on CFR
JM: Good idea.
Carlos: W will wait until September for putting these inCFR
Carlos: I don't have any progress. But I have started to review some of these during today
JM: No progress, working on #1804
which is a little bit tricky technically
... I started something about showing the CSS and JavaScript in
the rules, I am still looking into this
Helen: None at the moment
Daniel: One issue on rule HTML page title is descriptive
<giacomo-petri> #1861 input type image with empty alt attribute but not empty title
Giacomo: I have opened a ticket for browser vendors on my assigned PR
Carlos: If you have some time you can always pick up one of the "help wanted" issues and work on those :-)
<CarlosD> scribe: CarlosD
dmontalvo: ACT is working on
updates to the ACT Rules Format
... there progress to the automation to get updates from the CG
to the WAI website
Helen_: We are also addressing Urgent issues
<scribe> scribe: dmontalvo
<scribe> scribe: dmontalvo
Carlos: Based on feedback that we
got we are proposing a hybrid meeting on October 6 and 7
... We have gotten Dublin. Thanks Helen for hosting us
there
... As said above, we will be also hosting the meeting remotely
via Zoom toallow remote participation
... I expect more news to come during September
... Proposed agenda. @@ZQ suggested we could host a session for
newcomers
... for people woh might want to contribute to working on the
CG website or the automation for the WAI website
Helen: It would be good to meet with our UX people
JM: I think it makes sense to
have abroader session for people who are not yet in the CG. And
also for sompe people who is interested in the rules and need
to better understand them
... Also to organize Guinness Factory :-)
Helen: There is a hotel just down the road in Otpum offices
JM: It might be worth checking for accessible rooms there
Carlos: This was not on the agenda that you got in the email, sorry about that, but we need to have a look at this to unblock other things
Helen: I created a PR actioning
some TF feedback
... A couple of Jean-Yves comments
... 1. No example has a tabindex negative different from -1
JM: I am fine with the PR. I
think my comments would be improvements but happy to accept if
noone else thinks they are important
... I think we can make the assumption more generic
... Currently the only way to remove something from tabindex is
to use a negative tabindex value
Helen: I am leaving these
comments open, not resolving them
... Giacomo, you may want to take these as a reference when you
add examples in your related ones
JM: I just approved for people not to think that does not need a review because it has changes requested
Carlos: I think both of Jean-Yves suggestions make sense and I don't think they complicate the rule. These are objective definitions
JM: They are objective and
completely unambiguous
... Negativee tabindex is well-known in the accessibility
community, not so is top level and things like that
Helen: Maybe I should move it
JM: I can get to that tomorrow
Helen: If it's just moving things around, I can do
JM: I can do the move and the change in one go
Giacomo: Nowadays it is pretty frequent to see the input in different iframes for functional reasons. When you navigate the page by tabbing, you first need to navigate the frame and then the input. Not sure why the tabindex="-1" is a mechanism to take an element away from focus navigator
JM: The iframe creates a new
document
... There is a very strong difference techincally when there
are iframes than when they are ont
Giacomo: From the end-user it is not relevant, at least visually
Jean-Yves: I totally agree
Bob: You want to know that there is something that is taking you away form the content for security reasons
JM: It makes sense when it is an iframe that is including content from another website
Giacomo: Even if the payment gateway is on your site, the inputs need to still be out
Carlos: Created by Giacomo
Giacomo: About a specific
scenario with an input drop within a label and the label
pointing to a non-existing element
... And then an input with an accessible name calculated using
an element that can be modified by the user
... W3C validaro is flagging issues for those
... We are not talking about the content model but about the
syntax of the code to determine if 4.1.1 is failed
... The differences between our last conversation are those of
parsing
JM: For cases that are not
correct HTML and don't break 4.1.1 we need to decide what to
do
... Plus browsers don't do the same for each of these cases
Carlos: Looking at these two examples what we are saying is that they are both passing examples because they don't break 4.1.1 because they don't break any of the syntactic rules
JM: These are cases that we've
picked from the Accessible NAme Computation document
... They are not valid HTML but still passing 4.1.1, and the
accessible name group is also having discussion about changing
whatever needs to change to accomodate this
... Maybe we need to add to accessibilityi support that we
don't pay attention to these examples because they are
incorrect
Carlos: Probably for passed examples we want to show correct HTML
Giacomo: My first example is a real case
JM: I agree that we should stick
to correct HTML
... If we have a strong opinion on whether this should pass or
fail we should have an example. IF we don't have a strong
opinion, probably a note will suffice
Bob: I know there is an update to the Accessible Name Computation algorythm
<CarlosD> scribe: CarlosD
giacomo-petri: this example behaves differently in different browsers
JM: if we have this as an example, which is not valid HTML, then it might be understood that one browser is correct and the other is wrong
giacomo-petri: should we ask who wrote the accessible name computation about this scenario?
<Jean-Yves> https://github.com/w3c/accname/issues/154
Jean-Yves: I believe they would reply that this is not valid HTML so we don't have to tell you how to compute the name
CarlosD: So we want to address this with a note in the rule and not have a strong position?
Jean-Yves: Yes
BobD: does this suggest we need examples for pass, fail and undefined?
Jean-Yves: We use support notes
to identify when UA or AT does not follow specifications
... but in this issue, it's the author that does not follow the
specification
giacomo-petri: what about having an assumption that developers are using valid html?
Jean-Yves: We could have a rule testing for writing correct code...
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) Succeeded: s/zakim,, take up next// Succeeded: s/Philip:/Bob:/ Succeeded: s/Philip:/Bob:/ Succeeded: s/Nowadays/Giacomo: Nowadays/ Succeeded: s/Bob: When you/When you/ Succeeded: s/Bob: From the end-user/Giacomo: From the end-user/ Succeeded: s/Philip:/Bob:/ Succeeded: s/Bob: Even if/Giacomo: Even if/ Succeeded: s/ont relevant/not relevant/ Default Present: Helen_, giacomo-petri, Jean-Yves, CarlosD, dmontalvo, Philip, BobD Present: Helen_, giacomo-petri, Jean-Yves, CarlosD, dmontalvo, Philip, BobD Found Scribe: dmontalvo Inferring ScribeNick: dmontalvo Found Scribe: CarlosD Inferring ScribeNick: CarlosD Found Scribe: dmontalvo Inferring ScribeNick: dmontalvo Found Scribe: dmontalvo Inferring ScribeNick: dmontalvo Found Scribe: CarlosD Inferring ScribeNick: CarlosD Scribes: dmontalvo, CarlosD ScribeNicks: dmontalvo, CarlosD 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]