Conformance next steps

[rachaelbradley]

The group has been discussing which 1 or 2 conformance model(s) we will be exploring over the next 6 months.

Note: Within each conformance model that we decide to explore that uses percentages, we will try both points and percentages.

1. Please review the Pro and Cons Document and the 8 October meeting minutes.
2. Each comment below presents one of the four conformance options we are considering.

• Mark a thumbs up to each you think is worth exploring
• Mark a thumbs down if you would object to exploring that model. If you object, please reply in thread to that comment with your reason for objecting.
• Mark looking eyes if you are neutral on exploring the model.

Reminder that the up arrows do not do anything in this process.

[rachaelbradley]

1. Required plus percentage of enhanced provisions / guidelines

Level 1: Baseline (PreReq + Baseline)
Level 2: Baseline + x% of Enhanced provisions / guidelines
Level 3: Baseline + x+y% of Enhanced provisions / guidelines
(Potentially more levels at different percentage levels, or just leave it to the percentage to convey improvements.)

[GreggVan]

Can you provide a link to the definition of "enhanced provisions" ? Does this include ??

1. higher threshold items (e.g. contrast of 7 vs 4.5)
2. Assertions
3. other "first" requirements (requirements that are not higher threshold (see # 1) but are not in baseline
   - (will there be any of these?)

[rachaelbradley]

We are still in the process of defining what would be required (baseline) and what would be enhanced. See Conformance Conversations slides for some of the notes.

[dbjorge]

I 👎ed because I don't think that this approach offers sufficient means to ensure equitability of different functional needs. I think this approach would be extremely likely to result in folks meeting level 2 or level 3 conformance by omitting the provisions that are the most difficult to implement, which is not likely to end up equitably distributed across different functional needs.

[rachaelbradley]

Levels

Each requirement currently in Enhanced level is sub-categorised into levels, so you have to pass all of a level before you can move up to the next level. Like having a WCAG 2 A, AA, AAA, AAAA. AAAAA.

Level 1: Baseline (PreReq + Baseline)
Level 2: Baseline + “Enhanced 1” provisions / guidelines
Level 3: Baseline + “Enhanced 1” + “Enhanced 2” provisions / guidelines
Level 4: Baseline + “Enhanced 1” + 2 + 3 provisions / guidelines
Level 5: Baseline + “Enhanced 1” + 2 + 3 + 4 provisions / guidelines

[rachaelbradley]

[chair hat off] I think that this model would be difficult to do and would not allow us to meet the requirements we've set out to meet in WCAG 2. In particular, I think compliance would be set at a level and we would be back to where we are now with "required" and "optional." I think multiple 5 levels with % or points provides the incremental increase benefit that this does while still allowing some flexibility on what to meet.

[GreggVan]

Agree. Also I am afraid that it would result 8 years to our timeline to cover all the discussions about exactly which provision should go into which of the 4 enhanced levels (since this calls for each to be assigned to a particular level).

[dbjorge]

I'm confused about why this option is divided into 5 levels rather than 3 like the rest; I think it would make more sense to discuss the number of levels separately from the strategy for conforming to those levels. I wonder how many folks 👎ing are doing so based on not wanting so many different levels (for example, that sounds to me like that's the source of the fear Gregg expressed above).

My opinion of this option depends greatly on whether we allow ourselves to write individual provisions to include %s within the provision. Without that, I agree with Rachael's concern, but if we allow that, I think this becomes my favorite option. I think it makes more sense to treat the percentages provision-by-provision; I think it would be better to say "you can meet the level 2 text contrast provisions by having everything meet 4.5:1 and at least 90% of the page meeting 7:1", as opposed to "you can meet level 2 conformance by completely ignoring better-than-4.5:1 color contrast, but only if you meet at least 6 other provisions unrelated to color contrast".

[rachaelbradley]

My opinion of this option depends greatly on whether we allow ourselves to write individual provisions to include %s within the provision.

[chair hat off] While I like this approach, % by provision is how we approached conformance in the FPWD and the majority of concerns we heard back were that counting successes in order to create % required too much effort. We'd need to find a way to manage that concern.

[alastc]

I do think there's a need to discuss where this percentage is happening. I don't think anyone is in favour of by-instance (e.g. number of poor alt-texts on a page).
However, it could be at the Outcome level, or at the Provision level. I don't think we've fleshed that out enough yet.
E.g. For text-contrast you meet the baseline (4.5:1), then you have an "Enhanced requirement" for higher-contrast (7:1), and a separate assertion for following a style guide.

Do both get included in the percentage (by provision), or does meeting any enhanced / assertion within the outcome count?

[rachaelbradley]

3. Hybrid

This is a hybrid model of the previous two, where the group selects certain provisions / guidelines that must be included at level 2 and another set for level 3, but leaves the rest to the author.

Also, with informative documentation it could allow for specific regulators or sector-based organisations to mark certain provisions / guidelines as required at each level, independently of W3C/WCAG.

Level 1: Baseline (PreReq + Baseline)
Level 2: Baseline + x% of Enhanced provisions, must include X,Y and Z provisions / guidelines determined by AGWG.
Level 3: Baseline + x+y% of Enhanced provisions, must include X,Y,Z, A, B and C provisions / guidelines determined by AGWG.

[GreggVan]

Better than two since you are only dealing with two. I suspect that it might work even a bit better as

Level 1: Baseline (PreReq + Baseline)
Level 2: Baseline + x% of Enhanced provisions, must include X,Y and Z provisions / guidelines determined by AGWG.
Level 3: Baseline + x+y% of Enhanced provisions, must include level 2 "required" items

If it is important enough to require it for a level -- then it probably should be in level 2. But we can first try to implement this and then see if this is true or not

[bruce-usab]

we will try both points and percentage

If points are given for the Enhanced provisions, it seems to me this Hybrid model facilitates conformance claims with a bragging feature.

Presumably, a site conforming at Level 2 987 is more accessible than Level 2 456. A conformance claim of Level 1 98765 might still be fairly reported, but since the site failed X, Y, Z provision, it does not meet Level 2.

[rachaelbradley]

4. Required plus percentage across functional needs

All levels above level 1 include a certain percentage of outcomes, AND a minimum percentage of provisions / guidelines for each functional need.

Level 1: Baseline (PreReq + Baseline)
Level 2: Baseline + X% of Enhanced provisions / guidelines, must include A% of provisions / guidelines for each functional need.
Level 3: Baseline + Y% of Enhanced provisions / guidelines, must B% of provisions / guidelines for each functional need.

[alastc]

I like the idea in theory, but in practice I think it will be next to impossible to balance the enhanced provisions. Partly because the numbers are not spread evenly, partly because some provisions benefit multiple audiences (so those would become the default ones that people do). We'd be setting ourselves up for a very time consuming task.

[gundulaniemann]

At the first glance it looks nice, yet at the end it means the author is forced to spread efforts among several functional needs, instead of getting one done completely and then handle the next. at the, the Web site might still be unusable for most user groups, as each is supported by a certain percentage only.

[jenstrickland]

I agree that this may be challenging to deliver. However, what I appreciate is that it is an attempt to get more of the usually overlooked functional needs addressed. WCAG has a track record of missing many criteria for cognitive considerations while touting meeting assistive technology needs. This reinforces inequities that we need to be better at addressing. Providing clarity in the functional needs and how to serve them for all the users we are designing WCAG for — even when they require the subjectiveness of experience and expertise — will be key to the effectiveness of this model.

[alastc]

@jenstrickland - I think options 2 (levels) and 3 (hybrid) can mitigate those issues. Also, we (as the AGWG) should track the functional needs associated with each requirement/provision and aim for equitable outcomes (in the general sense of "outcome"). That doesn't mean the users of WCAG should have to do that work.

[GreggVan]

For all of these -- in order to assess them I think we will need

1. Clear definitions and a good set of examples for what all might fall into "enhanced provisions / guidelines"
2. definition of difference between a provision and a guideline
3. definitions of requirements, recommendations, assertions

and then we need to try to populate them and see which ones work and which break down ???

[rachaelbradley]

I agree but believe that is part of the exploration step after we decide which we will work on.

[alastc]

@GreggVan we do have starting points for these:

• The prerequisite / baseline / enhanced levels we defined at the top of the Conformance pros/cons document, and have a refinement at the bottom (yet to be discussed).
• We have so far been assuming there are requirements and assertions, but opened up discussion on adding recommendations as well.
• We also have the initial pass at what is prereq/baseline/enhanced from the chairs, and the categorisation exercise the group has been doing.

[yatil]

All of these are too complicated. WCAG has already the reputation of being too complicated. Having people who comply to pick and choose from a set of requirements or a percentage of requirements also means Level 2 or whatever does not mean the same on different pages. One site could implement Level 1 + ABC while the other would do Level 1 + GHI.

I also have no interest in becoming an accessibility accountant. The administrative overhead of many audits is already significant to no benefit to users or clients. These things need to be simpler, not more complex.

I also see min-maxing going on, where people will pick easy to get requirements to get over the % and miss others. But the most likely outcome is that nobody would bother to care for more than Level 1. WCAG AA only got real traction when it was required by law. Maybe we can make sure the base WCAG is good enough that we don’t need additional levels?

My idea would be to have WCAG, the core principles, as a standard without any levels. Requirements that would be in levels would be in different modules that you can be compliant against. This would free the modules from hard pass/fail requirements, and also make identifying websites using modules fairly easy. A WCAG+EasyLang website would always meet WCAG core and the easy language requirements. WCAG+EasyLang+SignLang would include sign language. Over time, module requirements could shift into the core, raising the floor for accessibility. In addition, modules could incubate and adapt more easily as separate identities.

[yatil]

Maybe we can make sure the base WCAG is good enough that we don’t need additional levels?

Sure, if someone could just define "good enough" whilst balancing understandability, feasibility, and equity then we'll have solved the whole thing!
More seriously though, we have a lot of user-needs that don't fit an easy true/false statement model, and a requirement to make it easy/desirable for people to go further than the 'basics'. Whether it is percentages, extra levels, or badges, we need something.

I am already serious (otherwise I would not comment). There has always been the option to go extra levels in WCAG, and they don’t work. There might be some lighthouse projects that implement WCAG 2 AAA, but in terms of broad acceptance, the SCs could as well not exist.

My idea would be to have WCAG, the core principles, as a standard without any levels.

That aligns with all the models above.

There is literally no proposal that says “No levels” above.

A WCAG+EasyLang website would always meet WCAG core and the easy language requirements. WCAG+EasyLang+SignLang would include sign language.

That's somewhat similar to the #121 (comment), but with badges rather than functional needs. I think badges / modules are a useful idea for higher levels, we'll probably come back to that once other things are in place.

Again “higher levels”, I think modularity is more important than levels, sorry if that does not come out in my initial comment.

In some of the proposed WCAG 3 conformance, it would be akin to A + 30% of AA but we don’t tell you which ones.

That isn't the case, it is more like A+AA + 30% of AAA and you choose which outcomes. (Or the group chooses some that need to be part of that, which is the main difference between the models above.)

This proposal says: “Level 2: Baseline + x% of Enhanced provisions / guidelines”, so A (=Baseline) + x% of AA (= Enhanced).

(Edit: Formatting)

[alastc]

#121 (comment) says: “Level 2: Baseline + x% of Enhanced provisions / guidelines”, so A (=Baseline) + x% of AA (= Enhanced).

Yes, so level 1 is the baseline requirements, which will probably be equivalent to WCAG 2 AA. Although we do not control what regulators do, that is what would be recommended as a regulatory baseline.

After that, it is all about building from that baseline and what would encourage people to do more. Badges/modules is another good option.

Also, this is one strand of work/discussion, we are also going through exercises to assigning outcomes to baseline/enhanced, and refining the phrasing.

[yatil]

Yes, so level 1 is the baseline requirements, which will probably be equivalent to WCAG 2 AA.

I understand that, my goal was to put what you do in WCAG 2 terms. In 2008, we would have said A is the baseline and AA is enhanced (and AAA “super enhanced”).

Moreover, if Baseline is equivalent to WCAG 2 AA, why not continue to use WCAG 2 AA? I can’t see anyone going to WCAG 3 just in case there is Enhanced stuff I would love to do voluntarily. (Nothing in accessibility happens voluntarily.)

[WilcoFiers]

I think there is a misunderstanding of the concepts of "baseline" and "enhanced".

No, I understand. What I disagree with is all this effort that's being invested in figuring out how to get people to go "beyond" the baseline. Most organizations fail to reach the baseline to begin with. That's the real problem, make WCAG easier to adopt, not harder like all of these proposals are doing.

[alastc]

We are putting some effort into encouraging people to get beyond the baseline, as per the requirements for WCAG 3.
In future, I think we also need some time into making "meeting the baseline" more practical for more organisations (e.g. with a product/site level conformance approach).

However, most of our current work time (in and out of meeting) is on the structure, phrasing, and usefulness of the core requirements.

[rachaelbradley]

Summary 16 October

[chair hat on] Trying to pull together the conversations up to now (October 15th 8:00 am Eastern)

• Required plus percentage of enhanced provisions/guidelines: 6 for, 3 objections
• Levels: 1 for, 6 against
• Hybrid: 9 for, 2 against
• Required plus percentage across functional needs: 2 for, 4 against

An additional suggestion of a baseline + modules above baseline was made within conversation with 7 thumbs up on the suggestion.

It seems like there is general support for the following, which we can discuss in today's meeting:

• A baseline set of required provisions that is somewhat comparable to WCAG 2.2 A & AA and a set enhanced provisions and assertions that can be used to build upon that baseline through points, percentages or predefined sets of provisions (modules). How those enhanced provisions will be used will need more discussion.

Concerns and questions that to note include:

• Would this proposal make it easier or harder for organizations to understand and adopt WCAG
• % require math and that seems to add complexity
• Will having enhanced options encourage adoption and if so, what is the best way to present enhanced (%, points, predefined sets) to help regulators use WCAG

Next steps would include:

• Clearly defining what would be required and what would be enhanced
• Discussing recommendations and assertions
• Defining each type of provision

[yatil]

FWIW, I don’t think it’s fair to count the thumbs up in my post as votes for my off-the-cuff proposal, it was embedded in commentary beyond the idea, and that commentary might have seen additional agreement.

[rachaelbradley]

The thumbs up and down inform our discussion at the meeting but don't dictate final decisions. The purpose of the summary here is to help members who have trouble navigating the entire thread. I added a link to your comment so others can find it directly.

[stevefaulkner]

I think we should seriously consider Eric's categorization model (modules) rather than baseline and enhanced as both are very loaded terms. Having user needs categorized into modules would be an incentive for developers/management to go beyond 'core principles'

[joelanman]

I agree that it might be a useful direction to look in for greater separation and understanding - basic universal requirements are a very different concept to 'enhancements', as seen in the current common misunderstandings of what AAA means

[alastc]

@stevefaulkner - these aren't mutually exclusive. We're generally in agreement that we need baseline requirements (/core principles) that work across sites, technologies and contexts. It is what we do with the rest that is the question (higher level requirements like higher contrast, recommendations, and assertions).

In that higher level (currently called "enhanced"), a percentage that allows for incremental improvements that you can track is one way. Modules would be an alternatives, and one that could be taken up from outside the group.

[rachaelbradley]

Final Resolution from 15 Oct 2024 meeting: We will explore having a set of required provisions that is somewhat comparable to WCAG 2.2 A & AA and a set of provisions and assertions that can be used to build upon that through points, percentages, or predefined sets of provisions (modules).