Consider removing “3.5 Sustainable solutions must be accessible”

[hidde]

As much as I agree that everything in 3.5 is a great idea, I would suggest removing it from this standard because:

• other standards, including WCAG, already cover accessibility, it is better to leave these recommendations to those standards so that this one can be more focused on sustainability
• testability is harder than the text suggests (see examples below)

Your website or application must conform to WCAG (at the necessary level), plus extend beyond to obey relevant laws and meet additional visitor accessibility requirements.

“at the necessary level” and “extend beyond” are vague. Necessary in a specific jurisdiction or necessary as in what users would need? “Extend beyond” isn't very useful in this spec without specifying how far beyond.

Needless to say, yes, it's good advice to extend beyond WCAG, I just feel this standard isn't the right place.

Enhance your website or application with Accessible Rich Internet Applications (ARIA) ONLY if applicable or necessary, and accessibility enhancing features when useful or beneficial.

When is ARIA applicable or necessary? What do we mean by “accessibility enhancing features”? Again, these feel like principles many would agree with, but I think they are too vague to include and even if defined in a more testable manner, probably not the right place.

[andreadavanzo]

Good point @hidde. I think that keep a reference to WCAG is important and it was mentioned in previous meetings. At the same time your observations raised very good point. What about this wording?

Proposed text

Success Criterion - Accessibility Compliance

Conform to the latest WCAG and meet applicable accessibility laws, directives, and policies. Go beyond these for making it more accessible.

Success Criterion - Using ARIA Effectively

Use native HTML elements whenever possible, as they provide built-in semantics and accessibility. Apply ARIA only when necessary to convey information or functionality not natively supported by HTML or when it significantly enhances accessibility and usability.

Success Criterion - Reduce Digital Inequalities (Human Testable)

Design and build products and services that help reduce digital inequalities, making choices that minimize barriers for users facing limitations such as slow internet, older devices, disabilities, or restricted access to technology.

Extended observations

I suggested "latest WCAG" because "There are three different levels of compliance in WCAG 3.0, like the level A, AA and AAA of WCAG 2. In WCAG 3.0, they will be called Bronze, Silver and Gold. Interestingly, WCAG 2.1 AA compliance will only equate to Bronze in Silver." (https://myaccessible.website/blog/wcagsilver/wcag-3-scoring-bronze-silver-gold-draft). Refers to a specific one would be difficult.

Moreover, I think that criterion 1 and 3 should be moved on UX (@ines-akrap) as they are more related to UX context rather than development context. IMHO, "Using ARIA effectively" goes straight to frontend/backend developers.

[AlexDawsonUK]

I'm generally in agreement that the best option would be to remove the content entirely, replacing it with a reference explaining the relationship between sustainability and subjects like Accessibility, Security, and Privacy (that are more adequately covered by the W3C). WCAG2 has a series of considerations that cover such subjects and cross-references explicit guidelines that are impacted by such issues, this is potentially how I could see us going about such an activity thereby referencing pre-existing W3C work and how WSG is affected by it.

This would also place us in a better position to "encourage" those spec writers to include sustainability within their work as part of our outreach and getting involved in horizontal review in the future (WCAG3 for example!). It's something we're discussing at our chairs meeting in two days time so we'll be sure to keep everyone posted!

Note: I would also point out that once tagging and filtering is available, the ability to group based on those subjects would also be a possibility for practitioners who want to identify the impacts of a specific subject like accessibility.

[andreadavanzo]

I am not sure about a "reference".

"Meeting every Success Criteria" is key for WSG. Simply referencing WCAG and not explicitly state as criterion discharge from the task to follow the WCAG. This is why I am suggesting the first criterion as "Conform to the latest WCAG and meet applicable accessibility laws, directives, and policies. Go beyond these for making it more accessible". Text is referencing to the "latest WCAG" extending to "accessibility laws, directives, and policies" which may exist in other countries or legislation.
The reference to "go beyond" encourages improvements rather than just meeting the minimum requirements.

Criterion 2
We could think to integrate with "3.8 Code must follow good semantic practices" and Success Criterion - Optional Features. However, here the scope is raise awareness that pollute the code with ARIA here and there just to say "Hey, my website is accessible" is not correct. (https://www.freecodecamp.org/news/web-accessibility-common-aria-mistakes-to-avoid/ https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Guides/Techniques

Criterion 3
Correct me if I am wrong, but WCAG does not cover all the points in the criterion, e.g. slow internet, older devices, or restricted access to technology. I think this is the reason behind the creation of extended policies like https://www.gov.uk/guidance/government-design-principles or "https://inclusive.microsoft.design/

Maybe think to change the title to "Sustainable solutions must be accessible and equitable".

[hidde]

Simply referencing WCAG and not explicitly state as criterion discharge from the task to follow the WCAG.

I think it's not helpful for us to require all (or any) of WCAG. With that one sentence we're adding 56 criteria, that require (at least partially) a different expertise to understand and evaluate, and they're also criteria that are already required by law in many jurisdictions.

Us including WCAG seems unlikely to really make a difference (positive or negative), while making WSG more complex to meet?

However, here the scope is raise awareness that pollute the code with ARIA here and there just to say "Hey, my website is accessible" is not correct.

With regards to accessibility, more or less ARIA is not the issue, it's using ARIA correctly; which is important, but it is covered in the ARIA spec.

I don't see how the criterion makes products more sustainable (scope of WSG), unless it is through saving bytes by removing nonexisting or redundnat ARIA attributes?

WCAG does not cover all the points in the criterion, e.g. slow internet, older devices, or restricted access to technology

True, slow internet, older devices and restricted access to tech are not covered, from our list only disability is.

Maybe think to change the title to "Sustainable solutions must be accessible and equitable".

What about "Sustainable solutions must be equitable" ?

[andreadavanzo]

other standards, including WCAG, already cover accessibility, it is better to leave these recommendations to those standards so that this one can be more focused on sustainability

I think we need to extend this to UX group (@ines-akrap) and up. On 2.x I see a kind of repetition/overlaps with what already required to WCAG. For example

• "2.2 Understand visitor requirements or constraints, resolving barriers to access": remove accessibility barriers is a fundamental WCAG goal.
• 2.9 Be attentive rather than distracting: Could be associated to Principle 2 and 3? Operable and Understandable?

I think it's not helpful for us to require all (or any) of WCAG. With that one sentence we're adding 56 criteria, that require (at least partially) a different expertise to understand and evaluate, and they're also criteria that are already required by law in many jurisdictions.

I would says that all the points on the WSG require a different expertise to understand and evaluate.

I don't see how the criterion makes products more sustainable (scope of WSG), unless it is through saving bytes by removing nonexisting or redundnat ARIA attributes?

yes the idea is to save bytes and make consciousness to use the ARIA properly

What about "Sustainable solutions must be equitable" ?

It's a yes for me. it depends on what we decide for the criterion inside ;)

Edited

Let me clarify. I don't want to raise flame or similar. What I am trying to say is that as been mentioned during previous meeting, even if WCAG is out for a long time, its adoption is still a fraction of the whole web. The idea to mention as criterion and not as reference is trying to push its adoption. WCAG as WSG are a recommendation and not a regulation. So mentioning a criterion does indeed imply to add 56 criteria but is still up to the person/organisation following the WSG.

Point 1.2.2 Guidelines says "Under the principles are guidelines. These guidelines provide the basic goals that authors should work toward to make content more sustainable. The guidelines provide the framework and overall objectives to help authors understand the success criteria, which are testable against, to implement better digital solutions.".

My interpretation comes from should and framework and overall objectives.

About a possible duplication/overlapping of some points and criteria on 2.x with WCAG I hope is interpreted as a pure personal observation grew up while writing in this issue.

[andreadavanzo]

After clarification on last meeting I suggest to:

• remove Success Criterion - Accessibility Compliance
• remove Success Criterion - Enhancing Accessibility

Proposed text

Success Criterion - Reduce Digital Inequalities (Human Testable)

Design and build products and services that help reduce digital inequalities, making choices that minimize barriers for users facing limitations such as slow internet, older devices, or restricted access to technology

[hidde]

looks good to me!

[airbr]

This looks good to me, just read the above now.

[AlexDawsonUK]

We have a Success Criteria under 2.29 that this proposed re-write feels fairly close to duplication that states:

The product or service regularly tests with weak, unstable, and slow connections, old browsers, and devices older than five years to ensure compatibility.

I propose a potential merging of your suggested re-write into the existing SC so that 2.29 reads as:

The product or service regularly tests with weak, unstable, restricted, and slow connections, old browsers, and devices older than five years to ensure compatibility, reduce digital inequalities, and minimize barriers for users.