<Carlos> scribe: ajanec01
Jean-Yves, the only place where it is used is heading is descriptive,,,
Jean-Yves, elemenet with role of heading which is visible or included in the accessibility tree, which section it needs to describe
Jean-Yves, Do we need to split the rule?
Carlos, has been looking at the section of content definition in terms of other rule. The definition seems to be fine. Is it really ambigious?
<Jean-Yves> https://github.com/act-rules/act-rules.github.io/pull/1085#discussion_r364145387
Wilco, what does a distinct part mean?
Carlos, it tells where it starts and where it ends
Adil, I agree
Wilco, that is an assumption
Wilco, there are multiple ways to explain it- hence it is ambigious
<EmmaJ_PR> +present
Adil, are visual headings coded correctly
Carlos, that is not what the rule is chesking
Carlos, we should rely on what can be determined programmatically
Carlos, WE SHOULD RELY ON WHAT IS NOT ONLY PROGRAMMATICALLY DETERMINED
Jean-Yves, splitting the rule might help
JEan-Yves, programmatically determined headings should rely on programmatic section of content
Emma, agree with Jean-Yves
Carlos, we all agree with it, but where does the section stop?
Wilco, if we do it only based on the heading structure we can include more in the definition
Emma, how much beyond the heading might be described
Emma, difficult thing to describe in the "programmatic" term
Jean-Yves, if we go with the definition of what the user perceives as a section of content doesn't solve anything
Wilco, list out the characteristics that commonly occur as a new section
Jean-Yves, css properties that describe a new section may not make sense to soemone who does not see the layout
Carlos, that's where splitting the rule may be beneficial
Emma, WCAG cares about the visual perception so that should be conveyed as well
Jean Yves, it makes sense to come up with the definition of headings
Jean Yves, The reason why we want ambigous description of section of content is because we want two testers give the same answer
Emma, programmatic section does not necessarily describe where the next heading is but where a section finishes
Wilco, I don't think that those things are required by WCAG
Emma, they are not required but they would indicate a section
Emma, if we say that the programmatic section catches something that is not part of a section then it highlights an issue
Emma, if there is an image before a heading that it is part of that section is that a problem?
Adil, we have headings without closing tags, how we can determine if they are programmatically determined?
Adil, check if it is coded correctly, and then determine the sections
Emma, that is what Jean-Yves suggested
Jean-
Jean-Yves, possibly we should look into the accessibility tree
Jean-Yves, it is amibious as it differes accross browser but the rule would be consistent
Wilco, heading should describe what is right beneath it, we don't necesarilly need to define a section. Maybe we should describe the begining of a section until the topic change
Carlos, that might also be ambigious
Emma, maybe we should use the programmtic section of content for level AAA
Emma, that would be a well defined rule that would be consistent. Then we can build on that
Emma, that would be an atomic rule that could later be part of a composite rule
Carlos, going back to Wilco suggestion- that could work. It is not that different what Jean Yves and I are discussing in Bypass blocks. Section of content in there is the repetitive block
Carlos, the immediate content under the heading must be described by the heading
Jean-Yves, could make sense
Carlos, immediate can not be ambigious
Adil, if the role of a heading is to break up large parts of content
Emma, could we have something that indicates the end of a section
Jean-Yves, the first palpable content could work
Wilco, I think that we've had a break through. Jean-Yves can you take it from there
Emma, I can see two things in the final call
Wilco, I do not
Wilco, changes requested on two rules
Wilco, #1381- I'm looking for reviewers
Adil, I will take it
Wilco, next one from Jay- that has change requests
Wilco, moving onto awaiting W3C resolution
Wilco, some of those things will come out soon
Wilco, object element has non-empty acc name
Carlos, a small editorial change
Wilco, does need final call
Wilco, the iframe one is not ready and won't be done by the 27th
Carlos, I will pick up focusable elements with aria-hidden
Wilco, I will put 10th August on the autocomplete
Wilco, we can put something about form element with autocomplete="off" would pass in the background section
Wilco, I've created an issue about it
Wilco, ok, let's wrap
Final thoughts
Carlos, very happy on the break through on headings
Emma, agreed with Carlos
Jean Yves, always enjoy the discussions in this group
Adil, good discussion and good work
This is scribe.perl Revision of Date 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: Carlos, Jean-Yves, Adil, Wilco, present Present: Carlos Jean-Yves Adil Wilco present Found Scribe: ajanec01 Inferring ScribeNick: ajanec01 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.)[End of scribe.perl diagnostic output]