Paths usage #754

Path are very important and are likely necessary to properly define use on single page applications. However, when paths are defined as elements on pages that leaves room to miss inaccessible content that could be encountered by people who use technology in different ways. For example, a screen reader or keyboard user may encounter content on the page before the elements in the path - for example, by navigating by heading, pressing tab, or by navigation with a landmark. Users with neurodiversity may be distracted by content at the top of the page or elsewhere on the page such as moving content - not to mention flashing or motion causing health issues for some folks. While non-interference type criteria can clearly be mandated - the subtleness of navigation with different technologies is more difficult to solve. Defining the path that users take may vary - what if a person strays out of the path and has difficulty getting back to it? Testing all page content on a path helps to solve this issue but then takes just back to covering all pages in a path. While there seems to be strong agreement on using paths for reporting perhaps there are ways to use them in reporting partial levels of conformance.

The challenge with paths is that I think they are ubiquitous in accessibility assessment, but there's nuance in the details of how they function when used in a audit scenario as a testable unit. A lot of the nuance comes from a product's particular architecture or organizational structure.

Just as a functional example, in audits I've done, we often have "Sign In" as a testable unit. The "Sign In" is tested and reported on as a single unit, but it is made up of multiple parts and pages:

• Sign In:
  • Enter Email and Password > [Destination Page]
  • Enter Email and Password > Verify Account (2FA) > Enter Verification Code > [Destination Page]
  • Enter Email and Password > Your Password is out of date, create a new one > Confirm Password > [Destination Page]
  • Enter Email and Password > Forgot Password > Enter Email/Phone Number > Confirm Account > Create New Password > Enter Email and Password > [Destination Page]
  • Continue with Google/Facebook/Apple/Partner > [Third Party Pages] > [Destination Page]
  • {and so on and so on}

I've worked in orgs where all of these pages/views would be owned by one team (except the third party obviously), and I've worked in orgs where some of these belong to different teams. In reporting the issues, we internally have to do the calculus of "oh it's this URL/component so log it with [team]", but at the same time we still apply labels in JIRA like "SignIn" and in audit summaries say "Sign In had 4 issues in this audit".

I've always included entire pages in path groupings, but carved out considerations for "global" components or sections like a global header/footer, mostly for internal reporting reasons in the sense of assigning to the correct team and not pinning one team's issues on another team. However, this is an example of something where internally the paths reporting looks different from external paths reporting, because for example if I have a global header keyboard trap, internally it gets assigned to the global header team to address and it's reported as their issue and not the issue of teams with pages that use it, externally the user is not going to know that and its reported as an issue that impacts the pages it appears on. If it did have to appear in something like a conformance report you probably won't say "Home, Search, and Item Page have a keyboard trap preventing navigation past [affected element]" but you probably will say "There is a keyboard trap in the header section of the following pages...".

All this to say I think our definition of paths needs to consider that "paths" are a top-level testable unit, each path will be made up of pages/views and those pages/views are made up of components. Depending on the particular needs or structure of the tester, when testing a path, they may focus on page-level reporting AND/OR component-level reporting, and that level of reporting may depend on the audience for the reporting (internal/external).

In response to some of the specific questions:

How is it written down so that it is repeatable?

Interpreting this as: write is down such that anyone who defines a set of paths for a given digital product, comes up with the same paths and boundaries.

I think that's impossible, and it is ok.

How consistent is it when different people choose paths on a website, and does it matter if they are not consistent?

I think it's ok if they're not consistent, that's something we accept for views too, and a concept like 'complete processes' in an evaluation methodology can be used by regulators to ensure that people are assessing complete processes.

How to avoid people skipping bits that fail, whilst appearing to show good accessibility.

This, to me, is a similar question to above: regulators or owners of an accessibility program should have an easy to use 'completeness' definition that makes this impossible, while giving well willing teams an easier and closer-to-how-they-work way to measure and categorise accessibility issues.

What about things outside the paths that affect the path?

Can we make it so that what affects the path must be inside the path?

If conformance is “all the paths available on X page/view”, then does it need to be part of conformance? That could be reporting.

I'd say it can be outside performance, inside the evaluation methodololgy, like complete processes is in WCAG-EM 2.

Can it be optional, so people can choose pages or paths as their conformance unit?

I think that makes sense. We can't predict well what's easiest for organisations, my expectation is that there are organisations and products where pages make most sense, others where views make most sense, others where paths make most sense. For some, multiple units make sense.

On an organisation level, if you are responsible for accessibility of hundreds/thousands digital products, would you want to want to require a specific unit for consistency? Or would you accept either/any combination, as all of them lead to an assessment of 'how accessible is your thing'? Can we assume that with some sensible guardrails, like not allowing exclusion of parts of paths or parts of pages, that assessments will roughly lead to the same conclusion regardless of unit?