scribe+ dan_tripp

all: introductions.

Standup / Project updates

<Jean-Yves> scribe+

<Jean-Yves> Dan_Tripp: project: "label in name" PR #2027. Helpful reviews. Working through them.

(that's it for projects)

project board link : https://github.com/orgs/act-rules/projects/2

jean-yves: wcag 3 work is also taking up our time now.

sorin: are contributions to wcag 3 anything we can contribute to?

jean-yves: process is unclear. wcag group is writing wcag 3 - still several years in the future. act rules will be a "replacement of wcag techniques". less ambiguity is the goal.
... I think you sorin would have to join the wcag working group.

giacomo: you must be a member or invited expert. reach out to chairs, Kevin White.
... I think you don't need to be a member of w3c.

kathy: surveys go out - unclear who to.

jean-yves: to AGWG I think.
... so you'd have to be a member of that, to receive the survey.
... but we also have wcag 3 work in the act group.
... we have a long list of pull requests. maybe too long. everyone is welcome to read those. best ones: PRs with editorial label.
... the older they get, the messier they tend to get.
... you're welcome to make comments on PRs. main focus: should each passed/failed example pass/fail wcag. (?)
... do we have a "beginners" label still? yes, just a few.
... maybe sorin also look at projects eg. label in name from Dan (PR 2075).
... it's not extremely well organized.

giacomo: (previous topic): one easy PR: failed example of "images of text". has label "reviewers wanted".

https://github.com/act-rules/act-rules.github.io/pull/2398

jean-yves: so - heading is descriptive: we had enough descriptive discussion in january. we had a survey.
... survey ended up being non-conclusive. very split choices between two of the options.
... hold on ... above links are wrong

<Jean-Yves> https://github.com/act-rules/act-rules.github.io/pull/2405

^^ correct link

jean-yves: so there's an a11y support problem. empty heading will be announced or not. we've raised the issue to wcag. they couldn't come to a conclusion either.
... so we'll remove examples that have an a11y support problem.
... so implementors will have flexibility. downside: they won't be harmonized.
... we'll add a background note explaining the situation. that this is inconsistent between different screen readers. and we couldn't reach consensus.

Risk of Subjective Editorial Judgment and Potential Impacts on Creative Content [b49b2e] - https://github.com/act-rules/act-rules.github.io/issues/2390

(armagan's sound isn't working)

jean-yves: I will summarize it best I can. armagan is challenging our "heading is descriptive" rule.
... many arguments. rule we currently have is comparing the heading accName to the first piece of content after it. IIRC we chose "first" piece of content because it wasn't too easy to define how far into the content we should go.
... you (armagan) think it creates a problem. not sure I agree, so it's difficult for me to be objective in summarizing your arguments.
... IIRC only total failures should be about total lack of information eg. totally generic headings. don't flag misspelling. don't flag creative writing.
... has anyone else had the time to read that?

kathy: reading through it now. I wonder if there's a way for armagan to summarize his suggestion.

jean-yves: there's a conclusion at the end with a summary.
... one of the arguments in the discussion is that this would increase the amount of work for testers, by making them read a lot of content. but it's my assumption that manual testers are already doing this. but maybe I'm missing something.

giacomo: from an a11y testing point of view, if you need to check if the heading is meaningful, you need to read the content. it may be time-consuming but you need to do it.
... limiting to the first sentence might be a problem in some cases.
... eg. heading = "my dog". first paragraph reads: "today I'm not going to talk about cats". (?)

anne: I haven't read the whole issue but it resonates with one of my concerns, after being away from ACT for a while. I found it strange that it said /first/ piece of content. it shouldn't go for what can be most easily tested. it should go for: what the SC is trying to accomplish.
... limiting it to "first" piece is really weird. so I agree with that argument.

jean-yves: so what I hear is: we should try to extend the rule beyond "first" content. eg. look at heading structure and take everything of same or lower level. assumes that the heading structure is not too messed up.

giacomo: I was thinking the same. say you have an h2. then you have an h1 (for some wrong reason - it should be an h3). then there's basically no content after the h2 (according to the "structure"). we went for the "first node" because it's objective.

jean-yves: but getting all the node until the next heading is also objective. it might be the wrong stuff if the heading structure is wrong. but that's another problem.
... armagan is saying (in zoom chat) that messed up heading structure is not a problem as per SC 2.4.6.

anne: a heading that is a heading for the last piece of content in the main section. if there's no programmatic division between that and the footer - according to "heading structure" it would make the footer content look like it's under the last heading in the main landmark.

jean-yves: in current rule no, because we say "first".

giacomo: agree that heading structure is not part of 2.4.6. but if the heading structure is affecting the content badly then it becomes part of our testing of 2.4.6.

sorin: say you have h1, has some content, then h2 , also has content. h2 would be part of content of h1, right?

giacomo, jean-yves: yes.

jean-yves: under the assumption that your headings are correctly structured etc.

kathy: when manually testing for this requirement, I would not stop at the first paragraph.
... going through some of the examples in the issue, eg. h1 "opening hours" - and content = "we're closed" - I don't think that would fail.

jean-yves: if the rule is passing even if page is failing SC. that is not ideal but not a big problem either.
... question for armagan: one of your objections is that the tester would need to be a specialist eg. science article is full of names that only a scientist would understand.

giacomo: AI could help.

jean-yves: currently, as a manual tester, how are you matching the heading to the content? and what if we don't have AI? like 2020?

kathy: that's the challenge with any equivalent / alternative description. eg. image of a chart. tester who doesn't know that domain can't test it.
... the tester won't be an expert in the content that they're evaluating. any subjective content will have that challenge.

giacomo: I think one of the points raised in AGWG backlog group was about: if the heading is not meaningful, for people in general (not just people with disabilities) i.e. it's a general usability concern.
... eg. an SR-only heading is wrong and failing. or if the heading is visible and not related to content, maybe it's a general usability concern.

jean-yves: a certain newspaper was making their newspaper headings jokes and puns. I stopped reading it.

shunguo: to me this is very generic and subjective. this is not about headings. also about accNames. image descriptions.
... 10 people will have 10 opinions. no end to this discussion.
... for this rule, we'll probably be hanging there forever. if we ask more people, we'll get more opinions.
... suggest we leave it as a background note and move forward.

jean-yves: subjectivity appears in many rules. we know it's here. it's acceptable. part of our work is to move the subjectivity to a place where we can't get rid of it. and get objectivity on the rest.
... so this "heading is descriptive": we can probably achieve objectivity on the "what should the heading describe" part. not the "is descriptive" part.

giacomo: maybe we need a proposal on how to extend the expectations so we're not restricting our assertions on the first available node.

jean-yves: this is the PR which introduced the the "first/next content" piece: https://github.com/act-rules/act-rules.github.io/pull/1425
... yes we need a better definition of "what the heading should describe".

<Zakim> giacomo-petri, you wanted to say that maybe we can work on providing a definition for context, that is not just the first available node

jean-yves: did we reach a conclusion? any additions?

kathy: I wonder with armagan on the call (without audio - only in zoom chat): I can see the problem with the rule as it was written. but is there a problem with the SC?
... my interpretation of some of the problems in armagan's issue is with the SC (not the rule).
... armgan says: "why is wcag telling how to write?"

jean-yves: we have a few rules in ACT about something being descriptive.
... image accName - doesn't quite say "descriptive".

miranda: coming from a usability testing background: what is the purpose of headings? they help a person complete a task. screen reader users use headings to determine which part of the page to read. task could be: finding information. or getting overview of page.
... so a heading needs to at least connect to the content in that section. and convey the scope of what's there. it'll never be complete. but it should be enough to help you decide whether or not you go there.

jean-yves: in zoom chat: armagan points out that headings aren't interactive.

shunguo: there is no question here about whether headings should be descriptive. in my mind the focus here is in our ACT rule: how do we do this?
... to me 2.4.6 is not only about headings. it's about headings and labels. labels are part of accNames.
... so 2.4.6 is also about accNames. headings and accNames.
... in ACT rules, how do we decide "descriptive"? of course it's very important. and difficult.
... difficult to implement, that is.

jean-yves: it is definitely subjective. and somewhere a semi-automated tool can help.

giacomo: I think discussion is derailing from scope of ACT rules. it's more about WCAG.
... not all WCAG SC failure cause the same severity of issues.
... just because headings are not a focusable widget, that doesn't mean the negative impact is small.
... screen reader users rely on headings.
... we don't tab through the page. we use the rotor - navigate by headings.

jean-yves: regarding example where content is repeated several times. yes we currently only look at the first one, and don't see the repetition.
... not sure what I would answer. but yes we definitely have this problem.
... time is getting short. maybe we can discuss again next time. hopefully armagan's sound will work next time.

closing remarks:

sage: good discussion. the scribing was bad - nice.

sorin: I like being here. discussion was chaotic at times. would like to contribute more.

miranda: you're tackling hard problems and I appreciate the work that you all do. good window onto what's happening behind the scenes.

shunguo: good discussion.

anne: I think I'll revisit our (my company's) methodologies for 2.4.6. then hopefully won't have to rewrite it all.

giacomo: interesting as always.

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/chairs, kathy/chairs, Kevin White/
Succeeded: s/my cat/my dog/
Default Present: Dan_Tripp, Jean-Yves, annethyme, Kathy, Sorin, MirandaCapra, giacomo-petri, Sage
Present: Dan_Tripp, Jean-Yves, annethyme, Kathy, Sorin, MirandaCapra, giacomo-petri, Sage
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.)