– DRAFT –
AGWG-2023-01-10

<Jennie> Is there a meeting on January 31st?

chuck: welcome. Happy new year.
… Any new members?
… Any new topics?

<Chuck_> https://www.w3.org/2002/09/wbs/35422/act-jan-2023/?login

(none)
… survey on Accessibility-supported 2 Subgroup Participation
… year since chaals joined us.
… culture check in next week

<JenStrickland> One thing: the equity sub-group will be prepared to present a report to the group on January 31.

<Chuck_> https://www.w3.org/2002/09/wbs/35422/culture_check_in/

jen S: equity sub-group will be prepared to present a report on the 31st.

CSUN https://www.w3.org/2002/09/wbs/35422/csun-2023/

chuck:

<Chuck_> https://www.w3.org/2002/09/wbs/35422/csun-2023/results

<AWK> +AWK

7 can't attend
… 3 may attend, 1 will attend a Monday AG meeting in person at CSUN if we plan to meet and nothing unexpected happens, 1 is attending.
… remote may be possible.

<JenStrickland> Apologies! I didn't see this survey before it closed. I will be presenting at CSUN, so could meet in person.

<mbgower> I did not see the survey, sorry. I can attend on teh Monday

<jeanne> I will attend remotely

RM: if we do have a meeting we will have it hybrid.

<Ben_Tillyer> I hope to join in person, but cannot confirm at the moment

chucck: may reopen survey.

Jan-March Schedule

<JenStrickland> * Jaunita, yes! We still ought to find a way to meet in person before — but these illnesses are a cramp to plans. I'm currently sick and keeping away from other people.

RM: will reopen survey

<Rachael> https://docs.google.com/presentation/d/1MUf5dY9NJjikBYJIo8az2uSVGm_A5RDNI3i8G9JsgD4/edit#slide=id.g1c642465f9e_0_0

RM: I have powerpoint presentation.
… Tentative Schedule
… Tentative Schedule
… Publish WCAG 2.2 by April
… CFCs to update content and restart CR in January (Ideally by Jan 17th)
… PR in February
… Publication in early April
… Final Deadline 30 April
… Publish an updated working draft for WCAG 3 in March
… Remove outdated content
… Include status markings
… Include an updated test section
… Possibly include options on conformance for public comment
… Close outdated issues
… Switch to new charter as soon as 2.2 is published

CSUN https://www.w3.org/2002/09/wbs/35422/csun-2023/

CEPC and queuing

<Chuck_> https://w3c.github.io/PWETF/

RM: want to highlight CEPC
… it establishes how we behave
… please follow the Code of Ethics and Professional Conduct

<KimD> p+

<KimD> Nope

<tzviya> the link for cepc is at https://www.w3.org/Consortium/cepc/

RM: For what to discuss and how we manage the que. we use q+
… linear form of conversation.
… we don't want to marginalize anyone. default is linear.
… chairs may support limited form of conversation in some circumstances.
… may also engage in topical conversations.
… However, linear que is the default so everone has a turn to speak.

kj: commend you for this.

ac: also can attach topic to your q+ which is helpful.

Will be shifting meetings (tentative)

<JenStrickland> * Thank you for the clarification on this!

rm: have not made a decision on this.

<alastairc> Attach the topic by saying "to" after q+, e.g. "q+ to say that topics are good"

rm: could spit this meeting after CR.
… we kind of do this now but could make it a more formal split.

shadi: welcome a separate meeting.
… worry about WCAG 3 only for 1 hour.

<GN015> +1 to Shadi, I share the concerns on reducing to 1 hour

shadi: could keep 2 hours for WCAG 3. and have additional meetings for WCAG 2.

<kirkwood> +1 to Shadi

chuck: won't make any decision without input and survey.
… opposite concern as shadi.

<Zakim> alastairc, you wanted to add context on the length of meeting aspect

chuck: need to balance time (chair hat off)

<Zakim> Rachael, you wanted to say that one reason is subgroups

ac: most useful are updates from subgroups and topics to make decisions.

rm: fruitful discussions in Sub-groups.

chuck: we're exploring options.

ACT Rules https://www.w3.org/2002/09/wbs/35422/act-dec-2022/

<Chuck_> https://www.w3.org/2002/09/wbs/35422/act-dec-2022/results

chuck: Approve new ACT Rules, December 2022 survey

Question 1 - New Rule: HTML page title is descriptive

chuck: 12 approved
… 1 wants adjustments, do not approve.

wilco: rules not only for auto tools.

<alastairc> Wilco's comment answers Stefan and Gundula's survey questions.

jd: concerns about icons, design, & PDFs

<Wilco> PDF is not covered by this rule. It would have to be a separate rule

<Wilco> Thanks for the suggestions on the icons.

chuck: reads detlev's comments.

<Jennie> Wilco - even PDFs displayed in the browser? It would be (I think) how the browser pulls the page title from the document.

chuck: (reads Michael Gower's comment)

chuck: (reads Stefan Schnabel's and Gundula Niemann's comments)

wilco: these rules are not meant to be fully automated.

chuck: mike do you have a proposal?

mg: could say this tile exists.

<Zakim> Wilco, you wanted to say that rule already exists

mg: nail down what description means.

<Wilco> https://www.w3.org/WAI/standards-guidelines/act/rules/2779a5/

wilco: that rule does exist.
… not sure what you would need or want from expounding on description.

GN: my concerns have been resolved

<Chuck_> proposed RESOLUTION: Accept rule "HTML page title is descriptive"

mg: need to get the link working

<Wilco> https://www.w3.org/WAI/standards-guidelines/act/rules/2779a5/proposed/#related-rules

mg: maybe some design tweaks.

Detlev: need to have auto testing or semi-auto testing explained.

<Zakim> mbgower_, you wanted to say should there be a place for prerequisites and dependencies?

mg: should there be a place for prerequisites and dependencies?

ac: there is a link.

<Zakim> Wilco, you wanted to talk about automated vs manual

ac: think we are fine. "Described" could be expanded on later.

<Wilco> https://www.w3.org/WAI/standards-guidelines/act/rules/c4a8a4/proposed/#implementations

wilco: we do have info on implementations documented.

<Chuck_> proposed RESOLUTION: Accept amended rule "HTML page title is descriptive"

<mbgower_> I agree the Related rules section is likely sufficient, thanks

<Wilco> +1

<Chuck_> +1

<jon_avila> +1

<Jennie> +1

laura: +1

<iankersey> +1

<Ben_Tillyer> +1

<alastairc> +1

<jeanne> +1

<JenStrickland> +1

<mbgower_> +1 with hopes we can get some better guidance on what constitutes 'descriptive'

<kirkwood> +1

<maryjom> +1

<shadi> +1

<Raf> +1

<GreggVan_> +1

<Detlev> +1

RESOLUTION: Accept amended rule "HTML page title is descriptive

<ShawnT> +1

Question 2 - New Rule: Image accessible name is descriptive

chuck: 11 agreed, one wants adjustments, one does not approve

gregg: ACT rules are not normative right?

ac: correct. we link to them from the understanding docs.

mg: concerned that "descriptive" is not clear.

<Zakim> alastairc, you wanted to say we need someone to sit down and work through those examples

chuck: mg are you okay with rule going through as it stands?

ac: does it support our understanded of the SC.
… need to do through examples MG mentions.

<Zakim> mbgower_, you wanted to say IMO, it's kicking the can down the road in regard to improving inter-rater reliability; maybe this is a 3.x problem

<J_Mullen> [apologies about that - my mute came off for a second]

mg: we are testing limited 2.x language.

<Wilco> +1 to taking a closer look at this for 3.0

<J_Mullen> all good alastair.

gregg: we are talking about image accessible name right? sounds like alt text description.

<mbgower_> Accname and description computation

wilco: effectively the same thing.

<mbgower_> https://www.w3.org/TR/accname-1.2/#:~:text=The%20accessible%20name%20and%20description,specific%20to%20individual%20content%20languages.

wilco: alt or aria-label

<mbgower_> sorry, this is a cleaner link https://w3c.github.io/accname/

gregg: maybe add it as a note?

wiclo: agreed.

<Chuck_> proposed RESOLUTION: Accept amended rule "Image accessible name is descriptive"

<kirkwood> +1

<GreggVan_> +1

<ShawnT> +1

<jeanne> +1

<Chuck_> +1

<alastairc> +1, happy for ACT to add a bit of text on alt-text providing the name

laura: +1

<iankersey> +1

<Wilco> +1

<Jennie> +1

<JenStrickland> +1

<Makoto> +1

<Detlev> +1

<jon_avila> +1

<mbgower_> yes

<mbgower_> OMG

<mbgower_> A cross reference to the other rule

<mbgower_> the 'exists' rule? Don't see it

RESOLUTION: Accept amended rule "Image accessible name is descriptive"

  Question 3 - New Rule: Element in sequential focus order has visible focus

<mbgower_> +1 with addition of other rule cross reference

chuck: 7 approved, 5 wants adjustments, one does not approve.

<mbgower_> please

chuck: reads Oliver Keim's comments.
… reads Michael Gower's comments.

<alastairc> I don't think I've ever come across the word "unicity" before, huh.

chuck: not sure what proposed change is.

<jon_avila> To Michaels comment, in my opinion this is about sequence focus order not anchors where focused is moved.

chuck reads detlev and awk's comments.

<AWK> I think that you made my point for me, Chuck!

<Chuck_> Maybe my intent ;-)

Gregg: shouldn't  says 1 pixel and 1 digit.

<alastairc> Until WCAG 2.2.. (hopefully)

wilco: WCAG doesn't give a threshold.
… could add it it but is not in normative language.

gregg: all of these do beyond normative language.
… suggest not having the test. It is dangerous.

<Zakim> Chuck_, you wanted to ask for scribe change

https://www.w3.org/WAI/GL/wiki/Scribe_List

<jon_avila> In my opinion I don't think we should add 2.4.3 focus order as this doesn't test for it - it's related but not covered by this rule.

<Zakim> mbgower_, you wanted to say I think my general feedback is I want more context. There should be a Related rules section as part of your template. There should be more context on constraints of rules

mg: talking about constraints and related rules. I want the documents to make sense to people coming in cold.

<mbgower_> got it

wf: these rules test for failures against the SCs. rules are never stricter than the SCs

<mbgower_> +1 to that notion. you can only check for the minimum: a 1-pixel contrast change is sufficient for current requirement

<alastairc> Which we come across daily

wf: I'd be happy to have more discussions about this.
… we've all agreed that no pixel change is a failure

<alastairc> Doesn't saying "in sequential order" take out the "back to top" targets?

wf: If focus ordering in the title is confusing, we can take that out.

<Zakim> GreggVan_, you wanted to say they are narrower but they should not be weaker. Stronger is ok but not weaker

<Wilco> Rules test for conformance problems of WCAG

gv: are these rules failure rules or rules to test the criteria? If it's a failure, it should be narrow. If they're failures, we should clearly call them that.

<Zakim> alastairc, you wanted to say that the title helps scope-out the skip targets.

ac: having the sequential focus order aspect I thought was a good idea. having that scoping is a good thing.

<jon_avila> I agree with Alastair

<Zakim> mbgower_, you wanted to say "orders some in the dom relative to each other" seems to be about focus order?

<alastairc> Chuck_ - Suggest we do question 5 (more process oriented)

<Chuck_> OK, thx. Question 5, then WCAG 2.2

<alastairc> Question for publication though - is it wrong? (I.e. misleading or would lead to incorrect results.)

mg: we don't necessarily want a focus indicator on something that's not interactive, but we don't want to ban it.

df: in testing, finding one non-visible focus stop generally isn't a big barrier. this sc would disallow that and would be fairly severe.

<jon_avila> I find it very confusing when I tab and there is no focus indicator at all - it makes me think I am missing something or that the indicator is broken

wf: I don't think this is too strict.
… as for renaming ACT to call them "failures" this is something we can revisit later.

JS: I've heard a lot about focus being on interactive elements, but I've seen in practice that non-interactive elements need focus.

<Zakim> mbgower_, you wanted to say that pressing Tab to reach items that take focus (sequential order) SHOULD always have a visible focus.

mg: I think that anything that gets focus should have a focus indicator.

<mbgower_> that's in 2.2, doesn't exist yet

GV: can't we engage the normative rules about focus indicator?

<Zakim> Chuck_, you wanted to say can this be tweaked and we review in a future call?

<jon_avila> SC 1.4.11 does require some contrast for focus indicators.

<Zakim> alastairc, you wanted to ask where to raise issues, and I thought it was HTML specific, and what we need for publication

<GreggVan_> ah sorry I was thinking 2.2 for sure

<mbgower_> I'm fine to accept as is, with understanding Wilco will update

<alastairc> https://github.com/act-rules/act-rules.github.io/issues

ac: it would be good to raise an issue for this.
… I thought these were HTML specific.
… what do we need for publication?

<jaunita_george> I'm an ADS and can help

wf: act rules have been exclusively HTML but they don't have to be. If anyone is a PDF expert and wants to help write rules, please get in touch.

<Zakim> GreggVan_, you wanted to ask when 2.2 is released will this one be automatically updated

<alastairc> Ah, it's covered in the "Applicability" section of each rule, so each rule is (or can be) tech specific

<alastairc> Informative content, not dependant on 2.2

gv: is this something that will automatically be released when WCAG 2.2 is released?

ja: can we put a note that other criteria might apply?

<Chuck_> proposed RESOLUTION: Accept rule "Element in sequential focus order has visible focus"

<Chuck_> proposed RESOLUTION: Accept amended rule "Element in sequential focus order has visible focus"

ja: if we put a note in there, people will be aware they need to check other criteria.

<Wilco> https://www.w3.org/WAI/standards-guidelines/act/rules/oj04fd/proposed/#background

wf: this is in the background information

<alastairc> +1, and for improvements: https://github.com/act-rules/act-rules.github.io/issues

<Wilco> +1

<ShawnT> +1

<JenStrickland> +1

<GreggVan_> -1 I think we should wait til 2.2 or include a note IN the item

<Detlev> -1

<Makoto> +1

<jon_avila> -1 as 1.4.11 is mssing

<mbgower_> +1 if Wilco can acknowledge my comment

<Raf> +1

<laura> 0

Question 5 - New Rule: Text has enhanced contrast

ca: moving onto question 5

<jon_avila> 1.4.11 is missing

<shadi> +1

wf: I need to know what to do to resolve these issues

<Detlev> @Wilco: I will communicate m concern vs. this rule (Element in sequential focus order has visible focus) via mail

<GN015> Have we skipped Q4 on purpose?

<mbgower_> Chuck, did you mean to skip 4?

<Wilco> Thanks Detlev

<Chuck_> yes

<alastairc> Wilco - JonA was asking for 1.4.11 to be referenced (in the background). Gregg's point I don't think is applicable.

<Detlev> @Wilco: What list would be most useful for that?

Question 6 - Streamline ARIA rule approval process

Question 6 - Streamline ARIA rule approval process

<mbgower_> +1 I agree with Gregg's comment

<alastairc> Gregg - other way around, ACT create the rule, and ARIA review. (But works in principle)

gv: I think we can delegate our approval to the ACT group. If they have a concern then they can bring it to us

<mbgower_> +1 for distribution to list

<mbgower_> +1

awk: what I'm describing in my comment is that we can add, remove, and update content quickly similar to the Understanding documents

<Chuck_> proposed RESOLUTION: AGWG grants ACT Task force amended standing permission to publish ARIA-specific rules as "approved".

<Zakim> mbgower_, you wanted to say that AWk's point about revistation is important

mg: Andrew's comment is really germane here.

<Wilco> Issues always welcome :-) This is iterative work

<mbgower_> +1

<Wilco> there is, we have a priority label

ac: if there's something really wrong, I don't know if there's a mechanism in github to say "this is urgent"

<alastairc> jon_avila - yes, there will be emails to the AG list.

<alastairc> proposed RESOLUTION: AGWG grants ACT Task force standing permission to publish ARIA-specific rules as "approved", with notifications to the list

RESOLUTION: Grant standing approval to publish ARIA-specific ACT Rules, once approved by the ARIA Working Group, with the resulting rules distributed to the AGWG list

<jon_avila> Great!

<Chuck_> proposed RESOLUTION: AGWG grants ACT Task force amended standing permission to publish ARIA-specific rules as "approved" (posted to list and if concerns exist AGWG can comment)

gv: sending it to the list and if there's a concern then AG can comment, then I think that ties up all the lose ends

<alastairc> Process would be: Email to the AG list including links to the rules and the github issues, then issues can be raised on github (or by reply), and ACT will act on those

<Rachael> +1 to either, slight preference to 1 week heads up

<Chuck_> proposed RESOLUTION: AGWG grants ACT Task force amended standing permission to publish ARIA-specific rules as "approved" (posted to list and if concerns exist AGWG can comment)

wf: I should always be able to give some advanced notice

<mbgower_> +1

<GreggVan_> +1

<Wilco> +1

<Chuck_> +1

<ShawnT> +1

<alastairc> +1

<jon_avila> +1

<AWK> +1

<shadi> +1

<JenStrickland> +1

<laura> +1

<GreggVan_> nice job

<Jennie> +1

RESOLUTION: AGWG grants ACT Task force amended standing permission to publish ARIA-specific rules as "approved" (posted to list and if concerns exist AGWG can comment)

WCAG 2.2 CFC Discussion (if needed)

4.1.1 removal

ac: we've got a couple of cfcs at the moment. The first is about 4.1.1 removal.
… leaning towards passing that cfc
… we've got several possibilities about how to deal with 2.0 and 2.1 which are currently unresolved
… in talking to certain stakeholders, it seems like a good time to make this change

Target size

ac: we had 2 things raised.

<Chuck_> I have a note on the sub-group report, tentatively planned for the 31st.

ac: one was the inline exception, one was target offset

ac: a change has been made in the pr. it seems editorial. if you have a comment, please raise it.
… between gregg and detlev, there was a suggestion for an update

<GreggVan_> +1

ac: suggests adding 'a list in the body of the page' as an exception

<mbgower_> Inline: The target is in a sentence or in a list in the main content on the page, or the size of the target is otherwise constrained by the line-height of non-target text;

ac: reads feedback from JA.

ac: we also had a comment from Mary Jo, who was concerned that it was becoming too web-centric.

ac: shows examples relevant to the new proposed wording
… anything that's in a list in the main part of the page would get an exception.

<alastairc> <strong>Inline:</strong> The target is in a sentence, or the size of the target is otherwise constrained by the line-height of non-target text;

ac: is this a worthwhile update to the sc?

<alastairc> Poll: Is it worth adding a specific exception for lists

<Zakim> mbgower_, you wanted to say the update is less webcentric and IMO amounts to the same thing

<Detlev> +1 to main content

<Zakim> GreggVan_, you wanted to say "I think your simple add of lists

mg having the actual list in here, it makes it much less technology specific. This solves some stuff without making it any messier.

<mbgower_> Inline: The target is in a sentence or in a list in the main content on the page, or the size of the target is otherwise constrained by the line-height of non-target text;

<Chuck_> Poll: Is it worth adding a specific exception for lists?

<alastairc> Poll: Is it worth adding a specific exception for lists? +1 for yes, -1 for no. (We'll do the 'how' next)

<Wilco> -1

<Rachael> 0

<GreggVan_> +1

<Chuck_> 0

<ShawnT> 0

<Detlev> +1

<GN015> -1 I feel lists are covered

<mbgower_> +1 either is fine with me, but I think from a non-html it is worth it

<alastairc> +0.5

<JenStrickland> +1

<AWK> 0

<jaunita_george> +1

<laura> +1

<GreggVan_> +1 because if you gave your list of lists most of the group would fail to score it correctly

<Rachael> How do we distinguish between visibly rendered lists and programmatic lists that are restyled?

<JenStrickland> Good question, Rachael!

wf: I think this adds more challenges than it answers. now we have to decide what a list is and what the body of a page it.

<alastairc> Proposed update: Inline: The target is in a sentence or in a list in the main content on the page, or the size of the target is otherwise constrained by the line-height of non-target text;

<laura> s/apporve /approve /

<laura> s/conserned /concerned /

gv: if you gave that list of lists to a group of people, I doubt they'd score it correctly.

<alastairc> Text lists were the most difficult examples we had for this exception

gv: I think that not having lists in there would be a serious mistake. I don't see any reason to not include it.

mg: I think I can live with either situation.

mg: the value of having the lists specifically in here adds value.

<mbgower_> Without the lists language, we can just add the explanation in the Understanding doc, IMO

<alastairc> "or in a list in the main content on the page"

ac: we need to resolve this in the next few days

df: maybe it's enough to say everything in the main content is exempt

ac: that would lead to quite a lot of content would be exempt that we wouldn't want to be

<laura> s/so everyone /so everone /

<JenStrickland> The main content of a page is subjective based on the user's purpose in a moment.

gv: maybe you could say "links that aren't used for inter-page navigation", although this could be any link

<Zakim> mbgower_, you wanted to say this is about sentence fragments

mg: the standard text on the web right now will fail because there's insufficient line height. we don't want every link to fail the guideline.
… the one area we looked at that failed everything was lists, which is why we're looking at this
… this continues to be a challenge with links inside the main body of the document.

<Zakim> Chuck_, you wanted to say time's up, discuss options

js: if something we propose would fail most things on the web and those things are causing issues for people, then shouldn't we address that?

<JenStrickland> Ah, thank you, Alastair, that makes good sense.

<Zakim> GreggVan_, you wanted to suggest "lists not for top or side navigation"

<JenStrickland> * Thank you, Gregg! The resizing does help.

<Zakim> mbgower_, you wanted to say increase line height will not necessarily be good for everyone

<Zakim> alastairc, you wanted to talk about top/side nav

<Detlev> it does sometimes

<ShawnT> hamburger menus

<mbgower_> but were any of those links in lists on the github page?

<GN015> need to drop

<JenStrickland> In many of the online word processing applications the line-height for lists is distinct from the normal paragraph text style. I often have to adjust because links in the list items end up being too close to one another and could be "fat fingered."

<JenStrickland> what if the bullets are hidden through CSS styling?

<maryjom> +1 to "bulleted or numbered" for lists in the exception. Not technology-specific.

<alastairc> Inline: The target is in a sentence or, in a bulleted or numbered list, or the size of the target is otherwise constrained by the line-height of non-target text;

<alastairc> https://docs.google.com/document/d/1khsB3Qo8P8VkvTOw2_akHJx_PiXF8HuZ6uKc7uyI1qQ/edit#

<ShawnT> can we use a list?

<ShawnT> instead of making it all one line

<maryjom> The target is in a sentence, is in a bulleted or numbered list, or the size....

<alastairc> Inline: The target is in a sentence, is in a bulleted or numbered list, or the size of the target is otherwise constrained by the line-height of non-target text;

<alastairc> Inline: The target is in a sentence, or is in a bulleted or numbered list, or the size of the target is otherwise constrained by the line-height of non-target text;

<alastairc> Inline: The target is in a sentence, or is in a bulleted or numbered list, or is otherwise constrained by the line-height of non-target text;

<alastairc> Inline: The target is in a sentence, or is in a bulleted or numbered list, or the size is otherwise constrained by the line-height of non-target text;

<alastairc> Inline: The target is in a sentence, or is in a bulleted or numbered list, or its size is otherwise constrained by the line-height of non-target text;

<maryjom> +1

<JenStrickland> +1