Meeting minutes
Chuck: We have a number of announcements
Alastair: We discovered shortly after the last publication we discovered a number of changes from our prior CFC were not incorporated into WCAG 2.1.
… So we need to republished 2.1 to incorporate those. That will make 2.1 how it was intended to be.
<Chuck> Shared Glossary: https://
Alastair: That will give a new publish date to WCAG 2.1
<Chuck> Pathway Folders: https://
Alastair: This is going to be a useful thing because lots of definitions will pass between the subgroups. It's just shared space to identify overlap.
Alastair: We have noticed that we set up all the pathway folders in the drive
<julierawe> Can you please reshare the link?
Alastair: All of it is currently in the 2024 folder. It would be useful to move those.
<alastairc> https://
Alastair: Maybe we can do this in the first part of your subgroup work.
Chuck: I have already moved our subgroup work in there. There is a lot of research information done by other groups. Do we want to leave it in its current location?
Alastair: Put the new stuff in the new folder. Link back to older stuff where relevant.
Gregg: I found it useful to put research into your current document in a different tab or something. We've been linking to it and copying over so it can be worked and commented.
<alastairc> https://
Chuck: The Mobile Accessibility task force (MATF) is looking for people to review the information just emailed out.
… Next week is our first meeting where we will be starting this call 30 minutes early for new individuals who need some onboarding.
MJ and DJ will be leading that.
Chuck: I will be shortly sending out a CFC for closing more silver issues.
Julie: I'm just catching up. So we're supposed to move things into our specific task folder?
Alastair: Yes, the things you're currently working on
Julie: So stuff we have that we will be working on later, for example, clear wording?
<Zakim> kevin, you wanted to make a final, final announcement
Alastair: If you're currently working on it, move it into your path folder.
Kevin: As you know, we have the AG meeting in person at CSUN. We have a room; conference organizers donated the room.
… Unfortunately the room didn't come with wifi. I have a quote from that. i would welcome any organization who would sponsor that and cover the cost of wifi. Get in touch with me separately ifyou think your org can assist.
WCAG 2.x update - Reflow
<alastairc> w3c/
Alastair: I'm going to share screen briefly
… There is a reason Michael Gower sent only one thing for review. It is a complete rewrite of the Understanding document for Reflow.
… Everything from the Intent heading down is essentially new or wholly revised.
… Scott took on the number of issues and did a whole rewrite.
… There are a number of ways to provide feedback. First general indication of support. Second provide comments on things you'd like to change. Third, provide specific editoral feedback in Suggestions, if possible.
… This is one big thing, rather than a bunch of smaller issues.
Introduce exploratory work on writing a note to support policy makers with uptake of WCAG 3
<alastairc> https://
Chuck: I won't bother sharing my screen, but we are introduce this to the group.
… It's where we start delving into what to provide policy makers for guidance. This is the beginning stages.
Alastair: In the discussion we just linked to, we'd like feedback on whether folks think we should include this, and what should be included.
… We will start initials drafts before the charter, if there is support. Then we can get more public involvement.
John Kirkwood: I'm interested in this. I've written policy on this myself. What problem are we trying to address?
Kevin: This has been a topic around for awhile. A challenge we know exists is how to integrate technical standards into policies and regulations. We know what should be considered, and there has been a desire to provide context for people writing policy or regulations on what they need to think about or questions to explore.
<Zakim> jspellman, you wanted to answer John about Silver work
jspellman: I was just skimming this. I see it references the WCAG 3 conformance, which came out of the silver subgroup.
… there are major use cases like small business and third party content.
<jspellman> https://
jspellman: I recognize a lot of this work from silver.
Shadi: To add to what Jeanne said, she and janina worked on conformance options. There are aspects which are technical and things that are policy-- and that WCAG will not solve.
… Conformance and compliance are related, but WCAG is not a law. So this could help policy makers understand what they can do in addition to WCAG.
… It might help draw lines about what is and is not in our scope.
chuck: Jaunata asked if we should be making standards for agentic AI
kirk: This is great. I would recommend you have a lot of people with experience of adoption of policy move it forward.
Shadi: This is not telling policy makers what to do.
<kirkwood> yes
<kirkwood> very good
Shadi: Previously the group has been vibrant. This is from a technical side covering what WCAG does and does not cover, and leave it there for policy makers to decide what they can do in their own regulatory framework.
Kevin: This is a quick response to Jaunita. AI is a topic being discussed in many different areas in W3C and beyond. There is a strong interest in exploring what the impact of AI is on standards work.
… You might want to raise that at a higher level than just AG.
Sub-group stand-up (quick update 1. anything which might overlap with other groups, 2. Where are you in the sub-group lifecycle, please update the pathways sheet for your requirements).
Chuck: We thought it might be worth reviewing crafting decision trees.
Alastair: This is the trickiest bit of some of the work we're doing. I'm going to share a document
… The main thing we're working on is what the requirements are. The decision tree is something we can do in the normative text to guide people.
… The complication comes in where we want to allow user agents to fulfil requirements or do it in different ways for different technologies.
… I'm looking at keyboard as an example.
… Under the Foundational requirements, the document looks at "view"
… Under that, there is one set of requirements.
… Because keyboard is so fundamental, we just have a list of 4 items to pass
… A more complicated one is focus indicators.
… There are two main checks, with one sub-item
… Text alternatives has a couple of different 'branches'. A decorative branch.
… Then, if it is an image there are a bunch of other considerations.
… Clear meaning has 3 checks, and a slightly different tree
… We experimented with this in the draft to see if it worked.
… The last one I'm showing is text appearance.
… We have have a decorative branch to start.
… Then we have a building box approach. We want some minimums.
… Then we have a branch for if the user can personalize/adjust the text.
… And based on the answer to that, a number of decisions to make.
… So there are some quite different assumptions that go into this.
Gregg: First of all, this is under the title of Requirments.
… The first thing asks a question. That's not a requirement.
… Then it says do these things underneath it.
… If it starts with "If" and wipe out the question, that would work. [real time editing in response]
… I don't they should be questions. It is listed as Foundational Requirements.
Gregg: These should be else ifs.
… Then you'd have "then" statements.
… Now it becomes a statement of a requirement rather than being a test.
… When it's listed as a bunch of questions, it looks like a testing regiment, rather than what you have to do.
… You are trying to make logic and make the sorting logic make sense to people reading it.
Alastair: I somewhat agree with a lot of that, but what I'd like to make sure is that we get a good spread of these to assess, because some of these would be different to approach. I agree we need to standardize, but we need to find the most readable format that works.
<Zakim> jspellman, you wanted to disagree with Gregg. This is a decision tree, not a requirements list.
<Zakim> Chuck, you wanted to say that gregg's suggestions sound too much like a programming language
jspellman: I would like to disagree with Gregg. This is a decision tree, not a list of requirements. To me it is much easier to understand, and follows the more common use of a decision tree. I would prefer to leave as questions.
Chuck: Initially what Gregg provided sounded like programming language, but then he qualified how to word it.
<kirkwood> +1 to Gregg cla rity given. if/then/else. of the ‘tree’ in title
Chuck: We do want to standardize, but initially that's a challenge. And I think it is a benefit to see how different groups arrive at their own decision trees. It will help us assess the best way to do this with plain language.
Gregg: You said it's a decision tree. To do what?
<kirkwood> or is it requirements?
Gregg: If it's meant to be something that says 'here are the rules', then you don't have a list of questions.
… If you want it to be used the way WCAG was used -- for standards -- this will need to be rewritten.
… I don't think it's bad to have a decision tree. But they will have to be written as rules.
<Zakim> alastairc, you wanted to discuss goals
<kirkwood> I have similar concerns
Alastair: in terms of the goals, it is to guide people to which requirements apply in their scenario.
… I don't think it's that different than an If/else statement.
… Each links should go to a primary requirement.
<Detlev> like the preconditions in Annex C of the EN 301 549....
<kirkwood> but this has value i would rather note call it a reqiements tree”
Alastair: In many cases it's giving an option for a user agent to meet rather than an author.
<alastairc> Detlev - I wasn't going to name that, but it was what I was thinking ;-)
Julie: In the example being shown, the first question in the decision tree was asking a question.
<kirkwood> just to not call it a “requirements tree”
Julie: Is it considered a best practice to have 2 acceptable 'yes' answers to a question?
Gregg: I was thinking about her question...
… My only other comment is this is logic. If this, do that. I think we can try to do that in plain language. At some point it is going to require for someone to do this legally.
… Half of people who go to college don't understand logic.
… We need to try to write in as plain a language as we can while making it clear.
… But the rules that will be put in the standards need to have clear logic.
Gregg: Logic is a talent, not intelligence.
kirk: This decision tree process is great. It shows how to do this. I do think calling it a requirements tree is wrong.
… We are just confusing ourselves with this.
<Laura_Carlson> +1 to John K
kirk: I think it's a good progresss. I just think the language needs to be adjusted.
Alastair: Thinking back to Julie's question on what the first question should be...
Julie: It was a different part of the doc, I think called "requirements tree". It was a different question like 'is the text purely decorative...
… Yes, Text appearacne.
Alastair: these are two things. Is the text purely decorative, or is it not intended to be read -- think of a giant letter watermark.
Julie: the "or" statement confused me.
… it seemed like there might be confusion in the wording.
Alastair: hopefully that is just a wording question, not a strucural
<alastairc> We need to work out the definition of "purely decorative"
mbgower: I want to point out that I think there is a clear desire to express a decision process in the way that is the most understandable to the most people.
mbgower: Gregg's statements on people's challenges with logic statements speaks to why it makes sense to make this more natural language.
mbgower: My sense is with that done, we can discuss later if the language has a natural transport into logic. ACT work demonstrates that there is a set of tests that are repeatable, etc.
<alastairc> Open to new names, it has morphed a bit since the start
mbgower: I suspect we will have a path to go to a more understandable decision tree. The actual decision tree where you ask a question and what you are trying to get at it has value.
<jspellman> +1 Mike
<Zakim> mbgower, you wanted to say how does somehting like ACT rules fit into this?
<Zakim> GreggVan, you wanted to ask "what decision" and can we change the title to match the function of the tree. Is it at "Test decision Tree" which would havd pass fail or an "Author Decision Tree" in which case it would be DO this or SKIP this or that" and not have pass and fail.
Gregg: My question is what decision are we trying to make?
… If it is a testing decision tree, it would say Pass and Fail
… If it is for the author it should be Do this
… So we need to determine if this is a testing or author decision tree.
<Zakim> alastairc, you wanted to say that - if you meet a requirement (or set of requirements) then it's a pass, but that's not a test-tree
Alastair: It is a tree for saying which requirements apply in your scenario.
… I think it is okay to talk about passing or failing.
Gregg: You didn't answer my question. Are you trying to say it's both?
Alastair: The techniques would be underneath this. It's trying to determine which requirements apply.
Gregg: Whether you use plain language or not, this is a logic tree.
<Chuck> +1 to gregg's observations on "logic"
Gregg: If you try to do this in plain language, it's going to be long and wordy, and it will not be usable in any other context.
… If you want to put in the techniques, that's great, but they will change.
… They need to be in a separate document.
<Laura_Carlson> +1 to Gregg
Alastair: that is the plan, to have techniques separate
Gregg: So this tree is not going to get in the WCAG document, some pieces will go in different locations?
Alastair: As in the current draft, we have a section "Which foundation requirements apply?
… That would have to be normative
<stevef> regrets for subgroup today
Alastair: But what I would try to finish with is that for the subgroups working, you need to have your list of requirements before you do a decision tree.
… The core thing is we have a set of requirements under each guideline.
Gregg: This will not be adopted by EN 301 549.
… The conditions should be on the requirements.
… This is going to be much more difficult to understand.
… I think this is a recipe for disaster.
… It will set us back a year or more
chuck: I'm going to cut off conversation here. We're out of time.
Chuck: We are not going to do group updates. The scribed portion is concluded.
Chuck: We will form a future agenda item about this.