Terminology

[rachaelbradley]

This discussion board will be for suggesting and voting on terminology.

• Each thread will start with a set of definitions.
• Please reply to the thread with suggested alternatives.
• Please thumbs up/thumbs down/watching eyes the various choices
• Please reply for each unique set of terms. If you want to only change 1 term within a set, post a new response with the new set of terms
• Reminder: The up arrow does not indicate anything in our process.

[rachaelbradley]

Scope

1. The smallest testable unit. They may be interactive components such as a drop down menu, a link, or a media player. They may also be units of content such as a word, a phrase, a label or error message, an icon, or an image.

2. All content visually and programmatically available without a substantive change. Conceptually, these correspond to the definition of a web page as used in WCAG 2, but are not restricted to content meeting that definition. For example, they could be considered a “screen” in a mobile app or a layer of web content – such as a modal.

3. A series of user actions, and the distinct interactive (1) and (2) that support the actions, where each action is required to complete an activity. They may include a subset of (1), (2) or a group of (2).

Examples include:

• Logging into a web site and being recognized as an authenticated user;
• Ordering an item, including the entire set of tasks from searching for the item, adding it to the shopping cart, paying for it, and receiving confirmation;
• Submitting tax information, from start to end of the process; and
• Interacting with other users in a virtual reality environment.

4. The combination of (1)s, (2)s, and (3)s that collectively comprise the web site, set of web pages, web app, etc.

[OliKei]

1. component level (UI Element level)
2. view level (including screens, dialogs, popups, etc)
3. task flow
4. app level

[ChrisLoiselle]

For context, WAI defines scope as https://www.w3.org/WAI/eval/report-tool/evaluation/define-scope and the related https://www.w3.org/TR/WCAG-EM/#step1 , so either this should be factored in to this conversation or obsoleted when a decision has been made that would merge these two ideas for WCAG 3.0

[GreggVan]

I am a bit concerned that we are redefining technical terms to mean something other than what they normally mean. Scope usually means the broadest range of things covered.

• The extent of the area or subject matter that something deals with or to which it is relevant. (Oxford)
• The range of operation or activity; the area covered by something. Merriam-Webster
• The range of a subject covered by a book, program, discussion, class, etc Cambridge

So my suggestion for SCOPE is

The range of ICT that this set of guidelines is designed to work for
Things I think ARE in scope

• Anything on the web that is rendered for view directly by user agents

  • pages, web apps, documents whose formats are rendered directly by user agents (html, pdf, rtf)

• Things I think are NOT in scope (but I may be wrong)

  • anything downloaded before it can be viewed or run
  • anything not on the web to start with
  • (as always - our guidelines can be interpreted and repurposed for other things - BUT
    • many of our provisions assume a user agent and a hardware device that has input mechanisms
    • that there are user agents that clean up our content (why we could drop 4.1.1)
    • that there are AT
    • and there are things we just do not address at all because we do not address hardware issues (since we can't (yet?) deliver hardware over the internet (and it would be a download? if we could?)

[ChrisLoiselle]

Regarding the vote in AG yesterday, I wanted to provide context as to why I mentioned products and/or services. On https://www.oracle.com/products/ , Oracle showcases that it has products, solutions and services. So including services and products seems a legit ask rather than embedding services as a subset of products. I'm just adding this use case as an example but would be open to whatever majority decides in terms of parent to child term(s).

[GreggVan]

Good point @ChrisLoiselle

some people view services as product. Some don't . If we are going to adopt the position that services are products, perhaps to avoid ambiguity we should say. "products (including Services)"

[rachaelbradley]

Test Types

1. Tests where there is a high degree of consistency between test results from different testers. Examples include testing whether certain properties exist in the content or if they match a value specified by the requirement.
2. Tests that rely on a individual evaluation based on existing criteria. Test results may vary between testers who understand the criteria. One example is evaluating the quality of alternative text used to meet a requirement for alternative text.

[ChrisLoiselle]

tests can be formative vs. summative, moderated vs. unmoderated, lab vs. remote, usability testing vs. expert review. Are we capturing all these definitions here ?

[GreggVan]

I agree with @ChrisLoiselle
We should start out with "why do we want to define these terms? " What dichotomy are we trying to highlight?

I THINK we are trying to separate those things that are reliably testable from those that are not. But we don't want to say "testable"/"untestable" because that pushes things we want to include off the table again. So we are looking for other words that can be used to include "untestable".

I don't think people understand quantitative and qualitative, but they like those words because they think qualitative sounds means a respectable (testable) form that is looser. And they have heard of "qualitative tests" so qualitative must mean testable in another way.

But that isnt what it means.

Qualitative statistics for example are

• the rank order of things 1,2,3,4 (No this is not quantitative -- this I qualitative even though they are numbers)
• a rating from 1 to 7

but these can be "opinions" if you will - of some type. Someone decided the order. Someone rated it 1 to 7

OR

they can be "order by height" where it is qualitative measure based on quantitative.

So it comes back to

• "WHY are we defining these terms" ?
• What difference does it make whether these things are qualitative or quantitative?

If we are doing this because at sometime in the future, we are going to say quantitative our testable and qualitative are not testable, and we are therefore going to treat them differently, then we should not be using these terms. We should be using the terms testable and not testable. Or, reliably testable and not reliably testable. Or whatever it is that we really mean and want the terms to mean because that's how we're going to use them. Trying to repurpose these terms and redefined them in our our own heads to mean something other than what they mean is not helpful. Also using them because some people will think they mean one thing and other people will think they mean something else and so both will be happy, itis only going to kick the can down the road and end up with arguments later.

We should know in advance what the purpose of defining the term is and how we are going to use it. Then we should pick the proper term for that use.

As far as I can see, the big elephant in the room is the fact that we all really really really want to be able to include more things in the guidelines than our able to be put into regulations. But we are worried that if we don't get them into the "regulatory, capable" group that everybody will just ignore them.

So I think our goal is to

• not try to make "things that regulators won't require" fit into some term where we think we can fool them into requiring them - but rather figure out how we can structure the guidelines so that
  • the things they can require are captured so integrally with the other things that should be done that they can't require that they cannot be separated
  • so everybody sees not only what is required but also what should be done beyond what we are actually able to require.

[rachaelbradley]

Chair hat on:
The purpose of this is to have terminology to discuss tests that can be used to meet WCAG 3. Long term we may decide to remove this terminology and for the time being we plan to move it to our explainer; however, it is helpful to have a shared understanding while we discuss conformance levels.

Chair hat off:
I see this as a continuum. What if we move to a more expansive set of tests?

In order of most repeatable to least repeatable, something like:

• Presence: Is something there or not (example: Language tag)
• Measurement: Does something meet a target or not (example: contrast)
• Equivalence: Is something comparable to something else (example: alt text to image)
• Quality: Does something meet a set of quality requirements (example: plain language requirements)
• Process: Has a process been completed or not (example: AT testing)

[rachaelbradley]

Summary from 10 September Discussion

Minutes

The group discussed different test terms but there was not a clear consensus. Additional discussion here is needed

[iadawn]

Is there a scale of objectivity to be considered as well?

[rachaelbradley]

When content works with Assistive Technology

Supported by users' assistive technologies as well as the accessibility features in browsers and other user agents.

This names the concept and section of WCAG 3 outlined in the Accessibility Supported Proposal.

[GreggVan]

This is always a tough one.

• I think it means (or should mean) that it is created in such a way that it will work with assistive technologies for all different types, degrees, and combinations of disability - that are available in all countries viewing the content and are affordable to users in those countries.

That is a lot of judgements and there isnt even any AT much less affordable AT in all countries.

AT that is built into operating systems is a good start though. Almost everyone everywhere uses an operating system to access the web. If your product will work with all of those features - that seems like a definable target.

We just need to get AT for all types, degrees, and combinations of disability built into the OS's. At lease good enough to use web - if not good enough to meet all of a user's needs

[alastc]

Just a reminder that this concept is trying to solve the problem of: How does an author know that meeting an outcome will work in practice with user-agents that are used by real people?

Chair hat off: We have a proposed approach already, but the name is confusing.

@scottaohara mentioned in the meeting that API supported & verified terms from OliKei would be better because of misunderstandings about how AT work.

I didn't really follow, I don't see how this proposal affects people who would test with AT and misunderstand how the AT works and complain about the site?

If something is "accessibility supported" or "AT supported", the idea is that the method/technique has been tested with a set of AT. If there are bugs in the AT, it either isn't supported or you claim an exception (an option in the proposal).

The people doing the testing are either those making the site, or testers on their behalf. If someone external finds a bug this actually gives you a defense as you'll have had a point in time when you know it worked with a particular set of AT.

@mraccess77 also mentioned that it isn't strictly about AT, it could be any part of the user-agent side. That is true, it's just that I think calling it Assistive Technology is a little more meaningful in this context. AT is also an umbrella term that can mean anything that assists the user.

[rachaelbradley]

Summary from 10 September Discussion

Minutes

The group discussed that Accessibility Supported is unclear but some members raised concerns about using Assistive Technology Supported. Additional discussion on GitHub is needed.

[scottaohara]

fwiw - i was largely opposed to the term "assistive technology supported" as that puts a lot of onus on the AT. I've read through the proposed approach and I think I'll have some feedback for that - but largely I think that draft text is a good start.

@alastc since you mention you didn't follow my arguments from the other day, maybe we can setup a time to chat? It'd take a lot less time to talk that out, then it likely would be for me to write up. then a summary of that can be written here?

[mraccess77]

I believe assistive technology supported is too specific. Many features we are talking about are not assistive technology but accessibility features - large text, browser zoom, dark mode. In addition, many folks are now referring to assistive technology as just technology.

[rachaelbradley]

@GreggVan “Products and Services” would be shorter.  Is there a benefit to creating a subset? Sent from my iPhoneOn Sep 11, 2024, at 1:19 PM, Gregg Vanderheiden ***@***.***> wrote: Good point @ChrisLoiselle some people view services as product. Some don't . If we are going to adopt the position that services are products, perhaps to avoid ambiguity we should say. "products (including Services)" —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[iadawn]

/me Team Contact hat off

When in ”service” design and delivery I always took and understood “service” to refer to the end-to-end provision to the client. For some services this could be wholly digital but for many there are physical elements to the service. For example, considering ordering some clothes from a website. You use the website to complete the selection and payment for the clothes but delivery is handled by a delivery company either to your door or to a pick-up service point. The former part of the service would fall within the realms of WCAG the latter would not.

For me this introduces an element of confusion to the words that we are using. Product, while perhaps not perfect, is at least simple and straightforward forward to define. And keeps the word count down 😁

My vote would always be for simplicity over introducing ambiguous terms with the hope of a more comprehensive label. I believe that adding in this term would really only fuel confusion.

[mraccess77]

I prefer to include products and services. Laws like the European accessibility act mentioned both products and services. Not all services are products.

[rachaelbradley]

We have been discussing what to call the various pieces of WCAG 3 guidance for internal conversations and the upcoming publication. We discussed this at the 1 October 2024 meeting and decided we would call the top level statements "Outcomes." We need to finalize the terminology for the rest of the structure for this upcoming publication.

A series of suggestions are below. Please give a thumbs up to any you would support and a thumbs down to any you would object to. If you object, please comment on why. If you have additional suggestions or combinations, please add them to the conversation.

This conversation does not address recommendations as that is an ongoing conversation we will have after this publication.

[rachaelbradley]

Outcomes
Provisions:

• Baseline Requirements
• Enhanced Requirements
• Assertions

[rachaelbradley]

Outcome
Provisions:

• Core Requirements
• Supplemental Requirements
• Assertions

[rachaelbradley]

Outcome
Provisions:

• Fundamental Requirements
• Supporting Requirements
• Assertions

[rachaelbradley]

Outcome
Provisions:

• Base Requirements
• Additional Requirements
• Assertions

[GreggVan]

All of the above omit RECOMMENDATIONS

I think this is one of the most important parts - and key for including non-testable cognitive, language, and learning (as well as other) disability considerations

Suggest amending all of these to

Outeomc
Provisions

• ________ Requirements (and recommendations related to each requirement - right along side it
• +__ Requirements (and recommendations related to each requirement - right along side it
• Other Recommendations
• Assertions related to recommendations