Meeting minutes
<LenB> present_
Introductions
Rachael: Asks for new folks or those with a new role to provide an introduction; no takers.
Announcements
<Rachael> WCAG EM published as consensus opinion. Decision at https://
<hdv> thanks everyone for your support!
Rachael: WCAG EM closed on July 10. Will be published as consensus decision.
<Rachael> Document Breakdown Survey https://
<alastairc> Probably best not to +1 after a CFC closes, we might send out another and overlap gets confusing...
<LoriO> just dropped again
Rachael: Announcement 2 - Survey has been put out based on last 4-6 weeks of conversation; link above.
… survey is focused on the conformance section only.
… survey will be closed to viewing others' comments to try to avoid 'group think.' All comments will be opened up after the survey is closed.
… in each question, there's an option for 'I've read it, and have no comment.' This ensures people reads and considers the question, and 'no opinion' can be captured.
<Zakim> AWK, you wanted to suggest a "I don't feel like I am adequately up to speed to form an opinion"
AWK: Survey questions assume that people have seen that people known and understand the questions; is there a way to address this?
Rachael: Understands the comment of wanting to get up to speed before answering survey; will take back.
<kirkwood> +1 to Andrew
Rachael: Feel free to use the comments field as well in the survey
<Rachael> TPAC https://
Rachael: TPAC is open. Group meeting scheduled on Monday and Tuesday; joint meeting on Thursday/Friday. Link above; please try to join in person or remotely.
WCAG 2 proposed changes https://lists.w3.org/Archives/Public/w3c-wai-gl/2026AprJun/0048.html
Rachael: Turns over to Patrick for the next item
<bbailey> https://
Patrick_H_Lauke: List of proposed changes that are in the backlog of the task force are up now. This starts the two-week window, and is open for comments.
Review WCAG 3 Topics for Discussion https://github.com/w3c/wcag3/wiki/WCAG-3-Topics-for-Discussion/
Rachael: Thanks for the highlight, we'll have another announcement next week.
Rachael: List of different topics for discussion is linked above.
Rachael: [shares screen] In GitHub, there's a WCAG 3 Topics for Discussion. It now complete and in an accessible format.
… meant to be a management tool. Placeholders for GitHub Discussions, Surveys, Minutes.
… Please take time to review to the topics to ensure the list is complete.
… For sub-questions (such as "What conformance model will we use?") that will be pulled out.
… please email the chairs feedback. Any immediate comments?
Paths https://docs.google.com/presentation/d/1BUg8Zagkyq7DgmM62erF1eJz-EQhDX69Ad4yxu2QP58/edit?usp=sharing
Rachael: (no comments)
alastairc: WCAG 3 Paths Update. [showing deck]
… this is a subgroup with Andrew, Shadi, Matt King, Wendy, Jeroen.
… [Shows slides, reviews content]
… [Terms slide]. Discussed but didn't settle on the terms.
Slideset: https://
<Charles> opinion: each term in the list has a unique meaning in experience and service design.
alastairc: For the sake of the discussion, we'll use 'paths.' "Flows" may clash with an English term and how people use them in their own org.
alastairc: Not conclusive, but overall direction is out lined on Slide 5
… [reads slide]
<Patrick_H_Lauke> as an aside, i like what i'm hearing in this paths presentation so far...
alastairc: "same interface, different content" problem is multiple pages and a template (such as Slack thread), and there's lots of different content
alastairc: there are a few mental models/approaches that people assumed that paths were.
… examples have been done in the background to see how we would break these down into parts.
<Patrick_H_Lauke> paths > "user journeys" to an extent?
alastairc: open question for the subgroup and this group, does this add anything useful to conformance?
alastairc: from my point of view, you'd still list a series of URS, but you'd have a slightly different way to report it. It doesn't change conformnace
… [reads slide]
alastairc: [describes screenshot of chat], reviews the example on the slide.
… This view included about 15 different paths.
… [shows slide Content site example]. Reviews content on Content Site Example
… There is guidance available for people to define this.
<kirkwood> Does a path consist of a change of context? meaning “in digital accessibility, a change of context is a major shift in a webpage that can disorient users reliant on assistive technology. Under World Wide Web Consortium (W3C) accessibility guidelines, it covers unexpected changes to the focus, viewport, user agent, or page content that alter the meaning of the page.”
alastairc: There are advantages and disadvantages to this [reads slide content]
alastairc: [reads slide]
… asks for queue
<kirkwood> +1 Good approach
GreggVan: 1) I think paths is a great thing for progress toward conformance, and guidance on where to start. But it doesn't work in conformance unless the sum of all the paths equals all the content
… 2) The process is different than paths. Process requires that you include additional pages. Paths says that you can exclude information on the pages.
… 3) I didn't understand the different URLs, but it doesn't really change things much
… 4) I don't understand what the justification could be that says that people with disabilities don't need access to all the info on the pages. You can't conform without being able to read/do everything nt he pages.
<Patrick_H_Lauke> the target/subject of a conformance claim as a whole would still need to be "the whole thing"
alastairc: Responding to Gregg. The way the subgroup discussed it was that it would need to cover all content.
<kirkwood> major benefit: gives a focus on context for user
<Zakim> Charles, you wanted to clarify if ‘series of’ means ‘specific sequence of’
alastairc: difference is the granularity of the thing you're commenting on conformance on. the guidance is for the how people can prioritize things.
Charles: For the vocabulary challenge. There are terms that have established meanings.
… it's not clear to me when we say a series of things that's intended to be synonymous with a specific sequence.
… There may be many paths, like adding an address in a checkout sequence.
… is the intention to identify a sequence of steps, or all the steps of the sequence that may be involved?
alastairc: If you have optional bits of a path, you would cover those on the 'branches' within that.
<kirkwood> opportunity to address the major issue of context and consistency for the first time, great COGA benefit
alastairc: each variation would be called out, along with the starting point, the end point, and any branches. Aim for complete coverage from a paths point of view.
… how to break that down is up to you in your scenario.
Charles: If the path can diverge, is it a different path?
alastairc: You have a choice, but it's important to have coverage.
Lia: If we consider any user-focused term like 'use case' or 'user journey' - I feel its basically the same.
… some products might be very complete, and might have dynamite user interfaces.
<giacomo-petri> +1
Lia: What elements might vary depending on what stage of the interaction the user might be, or how the user profile preferences?
… I do agree that users with disabilities need to have access to every single thing the same way.
<Patrick_H_Lauke> I'd assume a single path can include its various variations/iterations
Lia: but in working at a big company, I understand the level of effort and cost of fully verifying conformance for every interaction.
… if we want to make a call that we want to optimize people with disabilities can fully complete the journey, assessing every single element and component may not be fully feasible.
<Patrick_H_Lauke> e.g. "this path in light mode, this path in dark mode" all as part of the single path
<Charles> some of these terms mean the steps the user took versus the ones we think they should take to complete the action.
alastairc: In terms of coverage, I don't think it changes the amount of work to show that the interface is accessible.
… the proposal really just changes for the reporting to be granular.
Matt_King: When you have different variations in possible states for the functionality, you can change the nature of the UI, and therefore change the nature of the accessibility.
<Patrick_H_Lauke> the whole variation aspect is actually WHY this sort of approach is better than "page"/"url" approach
<Patrick_H_Lauke> ah, snap
Matt_King: you can get the amount of evaluation coverage in the scope that you want, because it's explicit.
… one of the challenges that we faced with pages/views was that just listing all the different things that can change on a page/view or defining the scope is difficult in dynamic apps.
<Zakim> Rachael, you wanted to ask about consistency
Matt_King: but you can have a flow that is as specific and has a clear purpose, and those various kinds of conditions and states are represented by the name of the flow.
<Patrick_H_Lauke> to rachael's point: is "consistency" needed? to me a path-based breakdown is a utility for the customer/person doing it
Rachael: Chair hat off. 1) If you did exercise in the subgroup how consistent were the results on how people identified paths.
… 2) If there are problems on the component level, how are those tracked?
alastairc: In terms of consistency between people, we had one attempt each and it wasn't consistent, but that was without instruction or prep.
<Jon_avila> Screen reader users and other users might need to navigate in different ways which require them to go through inaccessible page content to reach the path. So, I agree that anything on the page in a path would need to be covered.
alastairc: In terms of the things outside of paths that could be problems, the general idea is that everything needs to be included in the path.
… so that that thing should fail in a path somewhere.
… For non-interference ones, we need to check how they're phrased because they should be a fail.
Matt_King: For every single flow, evaluators would provide an assessment outcome for every single WCAG checkpoint.
<Jon_avila> Keyboard users still need to navigate to the path elements
Matt_King: All conformance defects were defined in terms of something, and how it could impact the user's ability to complete the path.
kirkwood: How would we handle a change of context through a path?
Matt_King: May need to look a the definition to fully meet that concern.
… in practice, teams would define the flows, which have a clear beginning and end of an activity.
GreggVan: Seems like the goal of this was to be able to report just the paths instead of the whole page or the whole site.
… If everything needs to be covered, what is the advantage of doing it by paths versus by the page.
… Why would we do the different types of reporting.
Lia: I'd love to learn how you're thinking about how this would change how people think about conformance and what they're implementing or prioritizing in the product.
… I feel there is a benefit of using paths instead of pages for us, esp because our products are complex.
<Jon_avila> I agree paths would be good for single page apps
Lia: I appreciate it as someone who also reviews VPATs and ACRs frequently, more specifically on what exactly was assessed is better.
… what do you think is the relationship with conformance, when we think about reporting with paths?
Matt_King: I think the question is trying to compare some other unit of analysis?
<Zakim> alastairc, you wanted to respond to Gregg and Lia
alastairc: Question seems to be "How would this change how people think about it?"
… It's a different way of setting up the testing and reporting on it.
<Zakim> Patrick_H_Lauke, you wanted to make quick note about consistency
alastairc: it doesn't change or improve the problem of the same interface. It would be a more granular way of setting up testing and reporting on that.
Patrick_H_Lauke: Riffing on a point that you had Rachael. This whole idea of breaking things down in paths is more of a utility for the customer or assessment person that things will be covered.
… From an auditor's point of view, it's clearer to an auditor to say that they are going to start and end somewhere.
… In the end, the subject of a conformance claim is still the overall product.
… To Gregg's Point, why aren't we just doing pages? I think it's because it's a convenience for the the customer and the auditor.
… it's much easier to define, particularly pages. It makes more sense to me to break it down, a page can be absolutely everything. A page can be a collection of anything.
<Zakim> Jennie_Delisi, you wanted to ask if paths would be used primarily for areas not covered in other criterion
Patrick_H_Lauke: If in the end you break it down for your convince you break it down by elements, components, or paths, it serves different audiences and purposes.
Jennie_Delisi: Hears three different scopes: 1) Criterion overall. Which criterion are applicable to the paths.
… 2) Severity of failure: Is the path related to the classification of the severity?
… 3) Is there scoping related to all the elements in the path, have we tested these things/
<Charles> my understanding is that paths represent the difference between (which) pages and whole domains versus the difference between (which) parts of (which) pages. path = these specific 10 pages conform versus this domain conforms.
alastairc: If you're testing a path, we're talking about a unit of conformance; creating a set of paths should include all the content.
… when testing a path, criterion should still fail.
… it's not a mechanism of prioritizing paths. It's something that could come later.
<Zakim> AshleeF, you wanted to note a real example encountered of when a path is interrupted by an issue in another path
alastairc: on the last question was on all the elements in a product, we test these things in path.
… you still want coverage in the same way. Difference would be that paths in this granular approach
AshleeF: 1) As a software engineer, when doing unit testing, it can be easy to get tunnel vision.
2) Real example where I've come across something like this was when they were observing a user on a web app. It had all kinds of drop downs and pop-ups.
… there was lots of complexity, example of needing to get into forms mode, and the user complete the task.
… 3) Wants to add a potential idea for the concept of defining paths. In terms of reporting, that may be part of the documentation.
… can the user reach the path?
<Zakim> Rachael, you wanted to react to AshleeF to discuss scribe change
Rachael: Scribe change
<Patrick_H_Lauke> (i need to drop - not doing it to avoid scribing, to be clear)
<Dirk> sadly have to drop soon. sorry
<Zakim> Heather, you wanted to comment on Gregg's comment - page to page reporting, such as focus order.
Heather: A few comments about testing and reporting methodology
… when it comes to testing for the criteria, is it sometimes requires it to be done on page to page to page
… Like on searches, so paths are important for these and cannot be independent.
<kirkwood> +1 to change in focus order
Heather: I am a fan of paths as help with users and possible litigation, was it prioritised right?
<Zakim> alastairc, you wanted to respond to gregg
Heather: It helps users to understand the critical paths and to prioritise fixes
Alastair: I wanted to respond to Gregg, but it was a while ago.
<Charles> +1 to idea that testing methodology varies when by page or by steps of a process.
Alastair: To Heather, we were aware of this type of objection and we wanted to include guardrails where it matches the WCAG 2.0 page conformance unless required to be path based.
… Communication internally and externally is important to the paths for user facing features and given that most sites are partially compliant, having path based versus page based will be easier for others to understand
… Also why do you dislike this proposal as we are trying to work on it and flesh it out
Matt: Alastair said most of what I wanted to say on the page being conformant.
… if you are in State A that is non-conformant and working to State B that is getting towards conformance, it helps the users know where the focus is going
<Jon_avila> I agree reporting on paths could be very useful even if the page as a whole was not fully conformant.
<alastairc> Granular paths is something that helps break down the perception of all or nothing in WCAG 2
Matt: using path-based scenarios helps on identifying the direction to focus.
… depending on the severity of the defect it helps on the fixing.
<Zakim> GreggVan, you wanted to say "Paths are fine as supplemental information but ALL conformance claims must include "All content on all pages(at all URLS) in the conformance claim conform to the requirements in WCAG 3 for level X" The claim can ALSO include any paths information - or none - and be a valid conformance claim. and to say "Paths are fine as supplemental information but ALL conformance claims must include "All content on all pages(at all URLS) in the conformance claim conform to the requirements in WCAG 3 for level X" The claim can ALSO include any paths information - or none - and be a valid conformance claim. But no claim can be made that does not include that sentence.
<Jon_avila> +1 on prioritizing based on components in common and critical paths
<AshleeF> I want to clarify the points I spoke on a few minutes ago.
<AshleeF> 1) As a software engineer, one thing that this makes me think of is when we are doing unit testing, it can be really easy to get tunnel vision. So this is related to paths that can interrupt the testing of other paths, possibly because there's some accessibility issue in the first one.
<AshleeF> 2) I wanted to note is a real example where I've come across something like this So this was an observability web app. It was very dense in the Ul elements: drop downs, pop-ups, filtering, graphs, etc. What happened is a blind NVDA screen reader user needed to reach content in the middle of a page, they came across an ARIA widget that was
<AshleeF> unintentionally coded as form element, and that forced the screen reader into forms mode. It disoriented the user and they element also trapped page focus/cursor.
Matt: part of what AshleeF mentioned with tunnel vision, part of getting to the start of the flow is helpful for the teams on how to fix and address it.
<AshleeF> 3) One idea related to testing and/or reporting methodologies - make sure that the path is actually reachable, so making that part of the test or analysis or assessment of testing a path is can you even reach the path?
<Charles> +1 to idea that path to a path is a new path.
Gregg: Paths are fine as supplemental information but ALL conformance claims must include "All content on all pages(at all URLS) in the conformance claim
… so you cannot make a claim just about paths
… helpful information about what conforms but information on all pages of what meets and how or do not, as getting into paths will become a Trojan horse
… we need to make it clear the paths versus pages conformance statement as confusing
Jeremy: The way I see paths currently as when working on it, we tend to subdivide the application into pages, but this doesn't always work as they do not split easily.
<GreggVan> "This is a report on non-conforming pages detailing those parts or paths through the pages that currently meet WCAG 3 requirements"
Jeremy: there are lots of ways and views to get into say a single page application
… if the application splits better into paths then it is ok, but it is about the paradigm on how the application works.
… I want to plus 1 the point on how we look back at WCAG and in WCAG 3,0 requirements to see if they can be defined in the terms of paths
kirkwood: I think this is great especially from a COGA perspective, or visual disabilities. Paths are important.
<Zakim> alastairc, you wanted to ask why it has to be pages, why can't paths be claimable?
kirkwood: buildings and managing that, you see the flow and the accessible route rather than just focusing on small aspects and it is an important paradigm we are missing
Alastair: I want to understand the unit of conformance to be agreed upon, and written down and understood so we know what people are claiming conformance for?
… Every time I go up a page the similarities are there. It is not about just paths, it is paths and pages together to ensure accessibility is tested accurately
… a page item would be the menus and buttons, but the path based is the people viewing when looking at my slides as an example
<Zakim> hdv, you wanted to add regulator perspective on what paths are good for
Alastair: we need paths as pages does not always apply
hdv: I agree with Gregg that paths can be complicated but I agree with Matt that they are required in places.
<kirkwood> +1 to Regulation we used it as well
<alastairc> hdv - paths as in sets of pages, or more granular?
hdv: but we have to look at regulations and how they are enforced. Like in the EAA, they use paths to work out who are the worst offenders.
… It is a pragmatic way to look at it outside conformance and normative of addressing paths in accessibility documentation to help users, companies and regulators.
<HaTheo> Office uses the concept of paths, we call them scenarios and freeway scenarios(mission critical scenarios that can have no blockers) and it it incredibly helpful for defining what we test regularly.
hdv: More granular to answer the question
<kirkwood> as a former regulator we did as well
<alastairc> kirkwood - sets of pages or the more granular approach being proposed here?
LoriO: When dealing with customer complaints it is often a user flow that is mentioned. But some application paths are extremely complex
… a simple login path is easy to document and test. But on some, documenting the exact paths used when jumping applications will be difficult to maintain and define.
<kirkwood> lmost awsuits a the result of proving an inaccessible path
<Rachael> draft Straw poll: Assuming paths provide coverage for all content within the pages that the paths touch: 1) Paths are a useful conformance unit 2) Paths are not useful in conformance but are in reporting 3 Paths are not useful in WCAG 3 4) Something else
Rachael: Chair hat on, but I have a draft straw poll:
… don't vote but help refine it please?
<HaTheo> @Rachael can we add this to a slide at the end of this to help define it?
GreggVan: Alastair when you said 50% is not a page but a path, this is common on pages. I want to help define paths to provide coverage to the pages as Rachael has added
… but it is not conformance. It is information only.
<Heather> Rachael - consider "Assuming paths provide coverage for all content and **functionality**...
<kirkwood> disagree with Greg can have an Accessible path
Matt_King: I think what I have been thinking is what you just said Gregg. If the only good thing in WCAG is when every page conforms 100%
… It is a nice idea but unrealistic
<HaTheo> +1 Matt King, I think paths help explain what is tested and how it is tested.
Matt_King: So realistically what is the value of conformance like the values of paths to a person like me with a disability?
… if you were more WCAG conformant you rob less of a life from me.
<wendyreid> +1 Matt
<Zakim> alastairc, you wanted to respond to Lori - I think it's the other way around in this proposal
<Adam> +1 to Matt’s perspective
Matt_King: I would rather have 7 out of 10 of the content conformant than 70% of the pages if the 30% has a blocker for me?
<HaTheo> +1 Alastair's view
<hdv> +1 Matt on daily use of <100% conformant products
<JeroenH> +1 Matt
<Jon_avila> I agree with Alstair - if you don't define the path through a complex site how would you know you covered everything?
Alastairc: Lori had a comment about paths being more complicated with more applications. It is actually the other way round, as it helps the complex sites but harder for simple sites.
<kirkwood> you definitely can use it for conformance (if done correctly)
Alastairc: what I am still not understanding is the "You cannot use this for conformance" statement. If I just focus on a small number of my pages as conformant to claim accessibility it is harder with paths
… I don't understand why one works and the other doesn't?
<HaTheo> +1 Alastair, I do think paths are easier for complex sites and also in explaining what and how it was tested. I do think many places use very similar examples to this for conformance.
Detlev: The way I see it you have steps to open a chat window or newletter process that is self contained as a path that we can test.
… We can have a more granular way forward to make sites more accessible. I think we need to update what we add to deem it conformant?
wendyreid: The way I wrestle is there are two ways to look at them? A path methodology as a unit. That can be huge and broken down into units
… Or a way of reporting on the usability of the product.
<kirkwood> if change in reading order is an accessibility blocker, how else could you measure it w/o defining paths?
wendyreid: As a user, it is easier to understand the accessibility of the paths versus the components on their own. And it will help on how you communicate it
<giacomo-petri> +1 to wendyreid point about priorities (and consequently testing feasibility/capability)
<giacomo-petri> capacity*
wendyreid: a large spreadsheet is harder to understand than using paths to be broken down to help with understanding. Unless the site doesn't lend itself to it.
<Zakim> Rachael, you wanted to strawpoll
Rachael: We have a strawpoll, it is not decisive but we can do it with the coverage or without the coverage.
… It is important to define the coverage. You either account for the view but 20 paths covers it, which is the coverage view.
<Zakim> alastairc, you wanted to comment on coverage
Rachael: The full coverage is included in the path but we just focus on the paths that can not cover some components?
alastairc: People should include everything, but we can't limit that in conformance. It is potentially undermining it if you exclude paths.
Matt_King: Is your conformance claim about everything in your site or part of the site? It is up to them to define the scope.
… part of this is getting lost, is the unit of conformance on if you meet it everywhere or in some places. So here you are saying it per path to help scope the conformance claim.
GreggVan: First we must agree on terms being used "Units of evaluation" are provisions like does it have captions?
… the components or pages or paths are very different. We have evaluation claims of what is tested, and conformance claims that are waht is met.
<Detlev> I have to leave, sorry - my +1 for paths as unit for conformance without including anything (the same way as you don't have to include all pages in a claim today)
<HaTheo> I think paths are helpful for describing the conformance claim and what is covered and how it was tested(a path or a page). FWIW, I don't think any page fully tests the page or every part of a page today with the page model as it's sort of meaningless for open ended rich applications today as they imply everything is tested and it's not...
<Charles> conformance claims today have no standard format. the unit of most reporting is a provision despite the unit of WCAG is a page.
<alastairc> this metaphor is just the same for pages, if you don't include all the pages.
<kirkwood> that’s exactly what we did in buildings, Gregg
GreggVan: if we talk about paths conforming for part of the site as it gets very confusing as can miss a lot out that are not accessible. They are misleading, as important to be included if they are there for everyone.
AWK: I don't think the subgroup has agreed if paths are partial or all inclusive
… I agree with what Gregg is saying that we should not miss things out, but currently in WCAG 2.0 we do not have this happening.
<kirkwood> +1 to Alastair
AWK: things have bugs, like buildings have issues, but we need a pragmatic way of marking this into conformance.
<AshleeF> FWIW, access in the built environment is historically segmented to only some paths. Some examples: disability parking spots behind a building while everyone else gets to use the front door, there being an elevator but it's a service elevator reached through a grungy hallway, single-stall bathrooms that are used as supply/utility storage closets.
<AshleeF> Extremely common, still very very very prevalent today.
Alastairc: Gregg's metaphor of the hotel missing paths out, the same can apply to pages as we miss pages out.
<Rachael> Strawpoll: With the understanding that the subgroup needs to better define coverage within paths, please weigh in: 1) Paths are a useful conformance unit along with pages/views 2) Paths are not useful in conformance but are useful in reporting 3) Paths are not useful in WCAG 3 4) Something else (please explain) 0) No opinion at this time
<Adam> 1
<Francis> 1
<GreggVan> 2
<AWK> 1
<kirkwood> 1
<Ben_Tillyer> 1
1
<bbailey> 1
<Zakim> Rachael, you wanted to strawpoll
<Eloisa> 1
<wendyreid> 1
<Makoto_U> 1
<Charles> 1
<LoriO> 2
<ShawnT> 1
<julierawe> 0
<JeroenH> 1
<jkatherman> 1, 4 - Paths are useful in both as a unit of conformance and are useful in reporting.
<Heather> 1
<Matt_King> 1
<kevin> 2 still lost on the difference between a path and a process
<Stephanie> 0
<alastairc> 1, potentially 2 if we need to use pages/views anyway.
<HaTheo> 1
<CClaire> 1
<Jon_avila> 1 are using in reporting and could be useful in conformance if they take into consideration other page content
<giacomo-petri> 0 I think we also need to understand how this will fit into the WCAG-EM and similar; no enough time to think about it
<AshleeF> 1, 4 - paths are also useful in something like evaluation methodology
<Rachael> 2 but maybe 1 if coverage is clearly answered and paths provide a clear way to define scope
<Atya> 1
<alastairc> jkatherman, AshleeF - if paths are included in conformance, it will by default be used in reporting
GreggVan: Andrew said nothing conforms 100% so we should use paths. That is unrelated!
<Jen_G> 0
<alastairc> I think Andrew's point was that, for things not 100% conformant, the conformance report will be more useful.
GreggVan: How many of us can say we have not broken a law? If we say we don't break traffic laws, do we make others optional?
<HaTheo> I think what Andrew was saying was paths help describe how it was tested so companies can feel comfortable making claims of Compliance.
<Lia> 1
GreggVan: the pages are the same as paths, I think it is obvious to what is included in pages bit not in paths.
<AshleeF> alastairc When I voted 4, I meant the informative portions of evaluation methodology, as in giving guidance for how to go about evaluation
GreggVan: Any page that you must use to get to another page is included, but in a path not all pages are used.
kirkwood: The comparison of buildings should be about the through path, to get through the building. Not random paths inside.
<Charles> i have a different understanding from what GreggVan described as a path. i have heard path = multiple pages, not part of a page.
kirkwood: paths is the only way to use the context for someone to get through the site. It is important from a COGA perspective.
<alastairc> Charles - if you look at the current slide, it is a series of elements that form a path.
kirkwood: It might be there but not across pages yet.
<alastairc> It could cross pages, but may not
wendyreid: I am not 100% sure what Gregg is getting at as currently we often use paths in testing now.
<kirkwood> +1 to Wendy
<AWK> +1 to Wendy
<HaTheo> +1 wendyreid, we don't think of things as pages, we define issues as with components when testing a path.
<Eloisa> +1 wendyreid
<kevin> Those could equally be called 'processes' though
<JeroenH> +1 wendyreid
<Lia> +1 wendyreid
wendyreid: what conformance report are we talking about?
<Jon_avila> Some accessibility reports like RGAA report at the url level
<alastairc> kevin - but that's a collection of pages, rather than a set of elements that may or may not be across pages.
wendyreid: I don't see the conformance report at a URL level. And we cannot control what people report. It is down to regulators to enforce and we cannot police it.
<AshleeF> If I may share two related works that heavily thoroughly discuss accessibility of the built environment (the first one is open access aka free to read): 1) Crip Spacetime, Margaret Price, https://
<Adam> +1 to Wendy’s perspective on policing
wendyreid: What we should focus on is how to define it.
<Ben_Tillyer> +1 to wendy
<Heather> +1 to Wendy
<Eloisa> +1 wendyreid again
Alastairc: I want to know what problems people have with the proposal, and thank you for that, and if you have any comments please type it in now or email me and the chairs.
<HaTheo> Do we have an existing space to discuss/define/debate this?
<Charles> same confusion. i answered straw poll based on approach 1.
<HaTheo> Helen you did great!
<kevin> Theo, the subgroup is working on this. If you wish to be involved, drop a note to Alastair
<Heather> you did great Helen :)
<Lia> thank you Helen! You did great
<kirkwood> well done!
<Jon_avila> Thank you.
<LoriO> +1 Helen!