SMART Requirements/Goals

[rachaelbradley]

As part of the charter process, we would like to resolve and capture the ways WCAG 3 will address its requirement document and include these as part of our schedule discussions.

The first step is to reach agreement on how WCAG 3 will address it's requirements. We are trying out the SMART format (specific, measurable, achievable, relevant, and time-bound).

We have captured ideas from previous discussions at SMART Requirements/Goals and listed each requirement as a comment below.

Instructions

1. Read the Potential Requirements/Goals.

• These are tied to the Requirements and Conformance Challenges Document in the left hand column. If you want to provide feedback on these documents please file an issue against them.

2. Consider whether:

• You agree with the solution and that the solution supports the requirement/challenge it ties to
• How to better clarify the wording to reflect the solution
• If the listed solutions are sufficient to meeting the requirement. If not, what should be added?

3. Add comments to this discussion or within the Google Doc.

• In general add suggested wordsmithing in the Google document using “suggesting”
• In general, add conversational comments to the Github discussion by reply to the comment that starts with the SMART requirement you want to discuss.

First round of comments due May 12th for discussion May 13th.

[rachaelbradley]

In order to provide broadened disability support, WCAG 3 will:

• Include requirements that only apply in certain situations [Define by Date & Example Date], and
• Include assertions for processes that don’t lead to repeatable results but have been shown to improve accessibility [Define by Date & Example Date].
• Add additional guidance for people with low vision and with cognitive and learning disabilities that was not included in WCAG 2.2 [Define by Date & Example Date].

[WilcoFiers]

But this is my point Gregg. This goal does not explain any of this. It's all well and good to agree in the abstract that "we'll have assertions for processes". But that doesn't mean anything until we start asking the hard questions. What processes will WCAG 3 allow assertions for? Is an assertion going to require a specific process to be followed? If so, those processes effectively become normative and will need to be put in the spec. How will that work? How will AGWG ensure that the processes it prescribes are effective? Is there some minimum bar for effectiveness? We do have that goal of WCAG 3 needing to be data driven after all.

If assertions will not prescribe processes and allow organizations to decide for themselves what process is appropriate, how will WCAG 3 ensure the assertions are still meaningful and effective? Alternatively we could go with the honor system on this, but then what does that do for the credibility of assertions? Is that an acceptable solution to WCAG 3's stakeholders?

What do we do about disability needs that we don't know effective processes for? That's the goal we're trying to address after all. If "assertions" and "outcomes" are the only tools in our tool box and neither of them work, what happens? Do we accept that we failed to meet our goal? Are we going to try and create such processes in order to meet the goal anyway?

I'm all for having SMART goals, but then these kinds of questions need to be considered in writing that goal. As proposed, these goals don't advance our work all that much. Most of the hard questions are left unanswered. AGWG has to do better than that.

[cwadamsoforacle]

@WilcoFiers, I'm addressing one comment you made:

I follow this work closely Alastair, I'm aware of the assertions discussion, but I tend not to participate. English isn't my first language. I don't have the skills to communicate my thoughts in text with the nuance needed here. Writing a response in these usually takes me half an hour to an hour.

I share similar issues with this mode of participation, for instance I too spend a great deal of time writing and editing before I post. Github conversations accommodate the needs of many, but not all. We also cover these topics and discussions in the AGWG call, which is the preferred way to participate by a number of our members who find Github less preferable. Are you able to join our AGWG calls to share your thoughts and comments?

We also have google docs that you might be able to use, where a lot of individuals and subgroups contribute directly to the work, but not all. We attempt to provide multiple ways to participate. For each topic, we try to:
• introduce it in a call,
• Provide threaded GitHub conversations with periodic summaries,
• Provide a Google document for direct comments, and
• Discuss points of concern on calls.

If GitHub is difficult, one option would be to thumbs down and note a one sentence topic that needs more discussion in the meeting. Then we can bring it to the meeting for conversation.

[detlevhfischer]

Include requirements that only apply in certain situations [Define by Date & Example Date]

I guess this this simply means that each requirement has (a set of) preconditions; captions only apply for content with video, etc. WCAG maps "not applicable" to pass whereas in EN 301 549 preconditions are effectively used to filter requirements based on the type of functionality present in the product (or site, or app, or VR environment...). Dose the above statement indicate more than that type of prerequisite filtering of one overall set of requirements?

[rachaelbradley]

Summary 20 May 2025 Broad Disability Support

Regarding this requirement:

• There is general support for this concept (9 up, 1 down)
• Much of the rest of this discussion relates to how we will do assertions and should be considered in Assertions Discussion #106.

A second point in this thread and google document, is that this format is not working. We need to step back and discuss:

• the objective for writing these,
• what they should be called,
• the level of specificity, and
• how to format them.

[GreggVan]

I think this format works well. Like democracy - it isnt perfect but all other approaches I have seen are worse. This is the best I have seen. Having them all in one place is very helpful. ALSO allows others to suggest additional ones and have them get the same consideration as these.

[rachaelbradley]

In order to make maintenance easier, WCAG 3 will focus on short names for requirements instead of numbers [Define by Date & Example Date].

[GreggVan]

See next comment for a example of the use of dots with shortnames - similar to way used for numbering

[GreggVan]

Here is what shortnames with hyphens or dots might look like (using the input section as an example )

• NOTE (whenever the last shortname is unique it can be used for short in conversation with the full string used to make lookup easier and to eliminate ambiguity.
• NOTE 2: Recommendations can have "(Supplemental) or (Recommendation) or (Informative) after their name. I recommend "Recommendation". Recommendations do not need to be testable, nor do they need to always be possible for all technologies or all websites even if using the same technology. This allows us to include more things than we can if we limit ourselves to testable things -- or things that are always possible or even things that may cause undue burden for some but others would like to make the extra effort or are implementing something where it is practical to do.

INPUT .................. {this is the SECTION}

Input.Combinations ................{this is the GUIDELINE short name}

Input.Combinations.Flexibility ............. {This is the first requirement short name}
Input.Combinations.Pointer-Keyboard-Focus
Input.Combinations.Gesture-Alternative
Input.Combinations.Body-Movement
Input.Combinations.Hover-Content
Input.Combinations.Flexibiility-No-Exception (Recommendation) ......{This is a RECOMMENDATION short name}
- NOTE: this might be listed here or could be listed directly under its related requirement above)

Input.Keyboard............. {GUIDELINE}

Input.Keyboard.Keyboard-Access-Actions ............. {requirements}
Input.Keyboard.Keyboard-Access-Content
Input.Keyboard.Bidirectional-Keyboard-Access
Input.Keyboard.No-Keyboard-Trap
Input.Keyboard.Keyboard-Access-To-Responsive
Input.Keyboard.Keyboard-Focus
Input.Keyboard.Relevant-Focus
Input.Keyboard.Conflicting-Keyboard-Commands

Input.Effort ............. {GUIDELINE Short Name}

Input.Effort.Logical-Order ............. {requirement}
Input.Effort.Standard-Navigation
Input.Effort.Keyboard-Focus-Preservation
Input.Effort.Repetive-Links (Recommendation)
Input.Effort.Comparable-Effort (Recommendation)

Input.Pointer ............. { GUIDELINE short name}

Input.Pointer.Simple-Pointer-Input ............. {requirements }
Input.Pointer.Pointer-Cancellation
Input.Pointer.Consistent-Pointer-Cancellation-Within-Set
Input.Pointer.Pointer-Speed
Input.Pointer.Pointer-Pressure
Input.Pointer.Consistent-Pointer-Cancellation (Recommendation)
Input.Pointer.Pointer-Speed-Adjustable (Recommendation)
Input.Pointer.Pointer-Speed-No-Exception (Recommendation)
Input.Pointer.Pointer-Pressure-No-Exception (Supplemental)

Input.Speech ............. { GUIDELINE short name}

Input.Speech.Speech-Alternative ............. {requirements}
Input.Speech.Voice-Identification
Input.Speech.Unique-Visible-Identifiers
Input.Speech.Real-Time-Voice-Alternative
Input.Speech.Front-End-Loading (Recommendation)
Input.Speech.Feedback-For-Speech-Commands (Recommendation)
Input.Speech.Unique-Visible-Label (Recommendation)

[detlevhfischer]

Just as food for thought: Some numbering schemes like the ATA scheme work with number blocks that are designed to allow more space for later additions. For example, imagine "Input" is "05" and "Input.Keyboard" is 05-01 and "Input.Keyboard.No-Keyboard-Trap" is 05-01-01. The two digit space means you could then have up to 99 possible different subsections of keyboard (because you may need more than nine) and 99 different outcomes for these. This might even extend to methods/techniques. So a (merely hypothetical) keyboard trap technique "Use CTRL - ESC to focus on start of page" could be given the number 001 (meaning in that number space you might have 999 methods/techniques for this outcome) and this method could be referenced as 05-01-01-001.

I admit this may be harder to remember than the current numbering scheme but it would be more extensible. If we would keep the method numbering independent of foregoing guideline / section / outcome numbering, it would also enable us to place the same method under two different outcomes. Ages ago I have discussed ATA numbering in my dissertation, just for those who are interested: http://www.oturn.net/top/App-II.html

[GreggVan]

@detlevhfischer

• That is what we have now in WCAG2 if you look at it.

  • But you are suggesting additional levels of breakdown? That works (See EN 301 549 example below)

• that solves the ordering problem - -but not the problem brought up on the call where people feel left out (designers etc.) when accessibility people keep referring to SC as 1.3.1 (e.g. when those who live in WCAG world say "Well I think that is covered by 1.3.1 but 2.3.2 is the real question for our site" it leaves designers and others in the dark and separated. )

By the way -- EN 301 549 uses number levels and introduces depth wherever needed to group related things. here is a piece of the EN 301 549 table of contents

5.1.3.14 Spoken languages 49
5.1.3.15 Non-visual error identification 49
5.1.3.16 Receipts, tickets, and transactional outputs 49
5.1.4 Functionality closed to text enlargement 50
5.1.5 Visual output for auditory information 51
5.1.6 Operation without keyboard interface 51
5.1.6.1 Functionality closed to keyboards 51
5.1.6.2 Input focus 51
5.1.7 Access without speech 51
5.1.8 Identify input purpose (closed functionality) 51
5.2 Activation of accessibility features 52
5.3 Biometrics 52
5.4 Preservation of accessibility information during conversion 52
5.5 Control using tactilely discernible operable parts 52
5.6 Locking or toggle controls 52
5.6.1 Tactile or auditory status 52
5.6.2 Visual status 53
5.7 Key repeat 53
5.8 Double-strike key acceptance 53
5.9 Simultaneous user actions 53
5.10 Authoring tools 53
5.10.0 General (informative) 53
5.10.1 Content technology 54
5.10.2 Accessible content creation 54

[jenstrickland]

Would it be possible to try some user experience research methods to test possibilities with a range of users?

For example, a card sorting activity with designers, engineers, etc., could be done in an open sorting method to identify what makes sense for users. Cc @jspellman ?

[rachaelbradley]

In order to make updates easier to make and adopt, WCAG 3 will provide a way for new requirements to be added to the published specification - new ideas start as best practices, move to supplemental requirements, and then to foundational requirements based on changes to technology and research. [Define by Date & Example Date]

[GreggVan]

So we are using the maturity tags (experimental etc.) to indicate maturity -- and things moving from best practice to something else would just be serendipitous. do I have that right?

[hidde]

Would that make it a living standard like HTML? Format seems helpful for HTML, but not for WCAG, where referring to specific version numbers (eg by laws, in conformance statements, in ambitions) is common and meaningful.

[rachaelbradley]

Summary 20 May 2025 Path for new requirements

• This concept does not have support but minimal engagement (1 up, 2 down)
• Discuss in meeting to see if we want to reword or drop.

[GreggVan]

There is a big difference between voluntary technical standards that can be continually changed and standards like this that might be made into regulations where the standard must be stable over time or it will not be adopted (since regulations are updated only infrequently (ofte 5 years or more) and can only refer to dated guidelines. Or different places might pick different dated versions and industry really does not want that. Impossible to build websites for international use with different guidelines in different countries- or with constantly changing rules.

We CAN constantly change RECOMMENDATIONS. That is fine. But changing requirements would be a problem.

[jenstrickland]

The idea of having best practices through the steps towards formal foundational requirements does make sense. I don't see a conflict for regulation. It's akin to A, AA, AAA, drafts, or the .x versioning. Regulators would use the actual requirements.

The challenge I see is that regulations currently expect a finished set of requirements to establish their rules upon. If best practices and evolving reqs are still in flux they can't use them.

Additionally uses like product owners, designers, developers, and QA folks will struggle with uncertain guidelines. It sounds like a 3.x evolution would be necessary.

[rachaelbradley]

In order to support emerging technologies and interactions, each Working Draft published will invite review by experts in the relevant technology.

[rachaelbradley]

Summary 20 May 2025 Expert outreach

This concept has support (7 up, 1 down)

• One point made is that asking for review is part of our existing process. This concept would be targeted outreach to experts.

[rachaelbradley]

In order to provide multiple ways to display the guidance, WCAG 3 will tag guidelines so they can be sorted and viewed in various ways such as in an order that supports testing, by technology or using POUR. [Define by Date & Example Date] This is further supported by WCAG 3’s focus on short names instead of numbers.

[alastc]

I had interpreted "supports testing" as a specific grouping or order that facilitates testing. For example, having all the requirements tested by keyboard in one group, voice input in a group, screenreader testing in a group etc.

[GreggVan]

Yes supports testing could be binary.

But it also could just mean Normative vs Informative since that should correlate directly with Testable I would think...

[alastc]

We are only talking about tagging requirements/assertions/best-practices in order to display them in a different order (or perhaps different format). By "supports testing", that could be grouping requirements so that it is easier to run through a particular order of requirements as a "tester". (Nothing to do with "testability" in the standards sense).

I think this particular example came from me, I group WCAG2 into 4 groups that are different from POUR. Not adding/removing anything, just ordering them so it is easier to run through testing a particular interface.

[hidde]

An added benefit of thinking of the guidance as content that can displayed in many ways, may be that it will be easier to build alternative interfaces, including our own, like the QuickRef and WCAG-EM Report Tool, and outside W3C, like internal tooling, government monitoring tooling and test engines.

[rachaelbradley]

Summary 20 May 2025 Tagging

This concept has some support (2 up, 1 down) but minimal engagement.

[rachaelbradley]

In order to be technology neutral, WCAG 3 will:

• State guidelines as user-centered statements and requirements as outcomes. Technology specific information will be included in methods. [Define by Date & Example Date]
• Where possible, provide at least 1 technology neutral method for every Requirement for those working in emerging technology. [Define by Date & Example Date]

[GreggVan]

not sure "user-tested" is the right word.

for example we don't want to say "users will be able to ..." because we know that not all users will. And if you mean "some" do you mean 3? Some user with extraodinary abilities?

And I don't think "user centered" has anything to do with being technology neutral.

Instead I would say

In order to be technology neutral, WCAG 3 will:

State guidelines and requirements as outcomes (what should be true). Add a user needs link to explain the range of user needs condisderted. And reserve technology specific ways to meet it for a methods document. [Define by Date & Example Date]

As to this sentence - I don't know what it means. If the requirement is technologhy neutral then I'm not sure I see the need for an example that is technology neutral. For some things -- there are no technology specific examples. For others - there may only be technology specific. I think an example of what you mean would be helpful here. Both to show where it is needed/helpful to add such an example and what it might look like.

Where possible, provide at least 1 technology neutral method for every Requirement for those working in emerging technology.

[Define by Date & Example Date]

[rachaelbradley]

Summary 20 May 2025 Technology neutral

This concept has mixed support (4 up, 2 down)

Suggested alternative wording:

In order to be technology neutral, WCAG 3 will:

• State guidelines and requirements as outcomes (what should be true). Add a user needs link to explain the range of user needs consider. And reserve technology specific ways to meet it for a methods document. [Define by Date & Example Date]
• Where possible, provide at least 1 technology neutral method for every Requirement for those working in emerging technology.

[rachaelbradley]

In order to support the widest possible audience, WCAG 3 guidelines and top level informative documents will go through a plain language review and issues will be corrected before final publication. [Define by Date & Example Date]

[GreggVan]

ALSO I would add

We will also include a "Goal" under each Guideline that provides a (longer) plain language explanation of what a guideline is intended to achieve -- where necessary bringing in user needs where they are not obvious/evident.

[hidde]

Added thumbs up, but wasn't sure about intended timing. I would like us to consider this much before final publication.

[rachaelbradley]

Summary 20 May 2025 Plain language support

This concept has general support (10 up, 1 down)

Requests to include a plain language goal on each guideline and to include plain language reviews before final publication.

[rachaelbradley]

In order to improve readability, WCAG 3 will:

• Break apart overburdened or complex SC, such as 1.1.1 and 1.3.1, into more granular requirements, and
• Separate requirements that produce more repeatable results (e.g. a video has captions) from requirements that may produce more variation in results (e.g. video has good captions). [Define by Date & Example Date]

[GreggVan]

Varied results = untestable ? in which case I would say / add "and grouping them so that recommendations or assertions are arranged next to requirements so they are seen and supplement requirements."

[rachaelbradley]

Summary 20 May 2025 Readability

This concept has general support (6 up, 1 down)

[julierawe]

I'm in favor of the first bullet, but concerned about the second bullet. Does that second bullet mean that anything that involves human review or human testing would be relegated to an assertion or recommendation?

[rachaelbradley]

In order to encourage adoption into law, WCAG 3 will:

• Continue to explore sampling methodologies and severity ratings, in addition to continuing the current pass/fail page based model that is used in WCAG 2, and
• Provide an informative note to support regulators seeking to adopt WCAG 3. [Define by Date & Example Date]

[bruce-usab]

What features for "adoption into law" are any different from features for adoption generally? Why do we believe that sampling methodologies and severity ratings are important to regulators in particular? USAB characterized WCAG 1.0 as not being sufficiently testable enough for 508, but when one compares requirements from WCAG 1.0 to original 508 1194.22 the overlap is close to 1:1. Yes, WCAG2 is widely adopted in regulation, but why conclude that is because of the current pass/fail page based model?

[GreggVan]

I think those are out of scope for WCAG. Sampling is a regulatory concept. We are the ruler. Sampling is not part of ruler activity - it is part of rule (how much, how often, and how to test) are all rule not ruler

It COULD go into an "advice to regulators" document but that is not part of WCAG 3. that should be made clear I think.

[rachaelbradley]

Summary 20 May 2025 Encourage adoption

This concept is not supported but has minimal engagement (2 down)

Discuss in meeting.

[rachaelbradley]

In order to motivate organizations to go beyond the minimal requirements, WCAG 3 will:

• Use a mechanism that is extensible by completing supplemental requirements and assertions beyond those needed for base conformance, and
• Include recommendations on how Accessibility Conformance Report (ACRs) could report on more than baseline conformance in an informative note on possible ways regulation can adopt WCAG 3. [Define by Date & Example Date]

[GreggVan]

ADD

• Positioning recommendations and other additional things that can be done to increase accessibility alongside/intermixed with the requirements as much as possible to help ensure that they are seen when looking at requirements

[rachaelbradley]

Summary 20 May 2025 Supplemental requirements and advice

This concept has general support (8 up, 1 down)

[rachaelbradley]

In order to provide a conformance model suitable for various sized organizations, WCAG 3 will:

• Include a smaller set of foundational requirements, and
• Require the foundational requirements and an author-selected subset of the supplemental requirements to meet base conformance. [Define by Date & Example Date]

[GreggVan]

Supplemental I thought by definition were NOT required. E.g. they are recommendations - not requirements.

If you try to separate requirements into two groups - you will have no end of argumets about things that should be in the other group. (may not be important for all users but for these it is what beaks the camels back - or is an absolute barrier for this group or that. )

[rachaelbradley]

Summary 20 May 2025 Supplemental Requirements

This concept does not have support (1 up, 2 down) but has minimal engagement

Discuss in meeting.

[rachaelbradley]

In order to meet its own requirements, AG will test the WCAG 3 documentation using the WCAG 3 requirements and address any issues found before the candidate recommendation stage. [Define by Date & Example Date]

[alastc]

I think the date needs to be essentially: 6 months before we get to CR...

[GreggVan]

"and address any issues" maybe be a bit hard unless "we decided to not change it " is addressing. Thre will be some comments that cannot be done/resolved/addressed except with a no/can't/don't agree.

[rachaelbradley]

Summary 20 May 2025 Testing with WCAG 3

This concept has general support (3 up, 1 down) but minimal participation

Suggestion to add a date of 6 months before CR

[rachaelbradley]

WCAG 3 will improve the ability to scale conformance by including methods that allow authors to pass when:
User agents* support the requirement, and
The author does not prevent user agent support. [Define by Date & Example Date]

*Note: For conformance, evaluators must declare the user agents used for testing within an “accessibility support set.” AG may recommend regulators define accessibility support sets for their areas of regulation within an informative note for regulators.

[mfairchild365]

My apologies if this has already been discussed; I'm new to the group. I suspect that there is a lot of nuance here. For example, can authors pass if only 1 specific user agent provides support and that user agent is very expensive and/or geographically locked, and/or not available in certain localizations, and/or is catered to one specific disability? I understand that the AG may recommend regulators define accessibility support sets, but I think it may be prudent for us to also publish a minimal support set (likely as something very generic).

[GreggVan]

@mfairchild365 EXCELLENT question/comment. We have genearlly meant "the most common free user agents" but I don't know that we ever wrote that down or defined it. Good question for the Working group.

Do we want to define - or maintain a list of (heaven help us) - which user agents have to support something before we say that authors can depend on it?

With coming AI augmentations in browsers -- this can be a much more relevant question. For example, if ALL the MAJOR free browsers automatically added alt text to any simple text that was rendered as an image when buidling their DOM -- could an author depend on this?

that is a simple example -- but there may be many more things that we ask authors to do -- that are done automatically by browsers in the future. how many browsers (and which) need to support it before an author can depend on the browser doing it?

[scottaohara]

another important aspect of this is getting agreement on what is even considered for "supports"

for instance, there are accessibility / usability features that browsers offer that can mitigate accessibility gaps with web pages. such as keyboard caret navigation (ie "navigate pages with a text cursor"), making links always underlined regardless of author styling, enhanced focus indicators... some of these features are only available in a single browser - some are in multiple - all of which (including AI support for images without alts) may or will need to be turned on by the user.

It is often asked that UAs create features to improve or meet accessibility requirements. But then when the UA provide these features, the conversation then seems to shift to "oh well... people don't know these features exist, so they can't be relied upon" or "these features aren't on by default, so they don't count as supported..."

WCAG needs to be very explicit in whether features a user needs to purposefully enable count as supporting requirements or not.

But if the decision is that such features don't' count as supported if they aren't enabled by default, then why should UAs prioritize the creation of such features? When will any requirement meet the bar as being met by a UA?

If accessibility requirements would result in author styles no longer being respected without people turning off the feature, then UAs wont' do that. Or if extra processing power needs to be used to automatically fill accessibility gaps by default, then UAs likely wont' agree to that either since it'd likely tank performance. That's why Firefox doesn't always have its full accessibility tree enabled. It makes the browser run faster without the a11y tree being constantly generated / updated.

[rachaelbradley]

Summary 20 May 2025 Accessibility Support

This concept does not have support (2 down, 1 up) but has minimal engagement.

Suggested alternative wording:

WCAG 3 will improve the ability to scale conformance by including methods that allow authors to pass when:

• user agents cause the content to meet the requirement without author action, and
• author does not interfere with built-in accessibility feature. [Define by Date & Example Date]

Additional conversation relates to #277

[julierawe]

This is such a low bar and reinforces the status quo. People can keep making inaccessible content, but as long as that content can be transformed by a user agent, then the author is off the hook? What about users who have no idea there is a user agent that can transform the content for them?

[rachaelbradley]

In order to better support dynamic websites, WCAG 3 will include methods for testing and applying requirements to templates, design systems, and style guides to address conformance. [Define by Date & Example Date]

[GreggVan]

change to "WCAG 3 support documents will include.....

[rachaelbradley]

Summary 20 May 2025 Templates, design systems, style guides

This concept has even support (1 down, 1 up) but has minimal engagement.

Suggested alternative wording:

In order to better support dynamic websites, WCAG 3 support documents will include methods for testing and applying requirements to templates, design systems, and style guides to address conformance. [Define by Date & Example Date]

[rachaelbradley]

In order to address the challenge of 3rd party content, AG will:

• include methods for testing and applying requirements for authoring tools to address conformance, and
• include a section on 3rd party content with an informative note on possible ways regulation can adopt WCAG 3. [Define by Date & Example Date]

[GreggVan]

WCAG doesnt include testing and applying information those are in support documents.

Also the 3rd party is rule not ruler and is not in WCAG. Perhaps in "Comments for Regulators" document - if we can create one.

In order to address the challenge of 3rd party content, AG will:

• include, in accompanying resrouce documets methods for testing and applying requirements for authoring tools to address conformance, and
• include, in an "Advice to Policy/Regulators" document, a section on 3rd party content with an informative note on possible ways regulation can adopt WCAG 3. [Define by Date & Example Date]

[rachaelbradley]

Summary 20 May 2025 Third Party Content

This concept does not have support (2 down, 1 up) but has minimal engagement.

Suggested alternative wording:

In order to address the challenge of 3rd party content, AG will:

• include, in accompanying resource documents methods for testing and applying requirements for authoring tools to address conformance, and
• include, in an "Advice to Policy/Regulators" document, a section on 3rd party content with an informative note on possible ways regulation can adopt WCAG 3. [Define by Date & Example Date]

[julierawe]

What counts as 3rd party? Is WordPress 3rd party content? Is a plug-in 3rd party content? Is an overlay 3rd party content? Can this draft requirement say more clearly that WCAG 3 will encourage authors to take steps to improve the accessibility of 3rd party content?

[GreggVan]

@julierawe Good question to ask

First -- this is not for WCAG but for our "policy advice" document. This is a RULE not a RULER topic.

Second -- We should very carefully define what WE think should be considered 3rd party and what we think/advise policymakers do about who is responsible or not for it.

My Understanding -- from discussions in WCAG 2 and WCAG 3 is that it is something like

3rd party content
Content that is not under the control of the author/host of the web content

• where Under control of the author/host of the web content means that the author did not create the content nor did they contract or choose or otherwise remunerate some other party, in any way, for the content

EXAMPLES of 3rd Party content include

• email in an email program
• posts made to an open forum
• a document in a document authoring program or a document reader

Examples of content from another source that would not be considered 3rd party

• the checkout pages of a shopping site where the shopping site pays another organization for their checkout function
• content commisioned by the author/host and incuded on their pages
• a compendium where the author/host selects and pays people for their posts to the blog
  • exception -- would be an open forum where anyone can post but they are remunerated for their posts. (e.g. if you review our product we will include you in a drawing. All reviews that follow decorum are accepted. That would be an open forum rather than commissioned work )

there will need to be a lot more thought and discussion and examples yea and nay before we settle on a definition of 3rd party content. It is easy to get wrong. But this should give a starting point - along with examples from previous document created by a subgroup that Shadi worked on.

[rachaelbradley]

In order to make it easier for others to apply WCAG 3 requirements to non-web technologies, WCAG 3 will:

• State Guidelines as user-centered statements and Requirements as outcomes, and
• Where possible, provide at least 1 technology neutral method for every Requirement. [Define by Date & Example Date]

[GreggVan]

This is an ECHO of a previous set of statements (4 items above this one). See comments there

[rachaelbradley]

Summary 20 May 2025 Non-web technology support

This concept does not have support (2 down, 1 up) but has minimal engagement.

This may be repetitive.

[bruce-usab]

From call today, and some sentiment expressed that something practical/useable needed to be published during the charter period, should we explore prioritizing/deferring/sacrificing some requirements? Would it have utility for WCAG 3.0 to only be useful to authors already comfortable with WCAG 2.x?

[GreggVan]

@bruce-usab Thanks for capturing and posting the concept from the meeting here so it gets discussion

My thoughts

I don't think we should put out anything til we are done -- except drafts for comment or resource documents.

If we do - then what would/should people do with it. Stop using 2.0 and use it? Use both 2.0 and it (and what if there is a difference in specs?)

Resource docs like

• "recommdations beyond 2.x "
• "Common Keyboard Navigation Commands"

can be useful. But not anything normative I don't think