Proposal: 2.29 Regularly test and maintain compatibility

[jenstrickland]

THIS IS NOT A PROPOSAL!

Continue discussion with a due date of November 1, 2025.

Revised

2.29 Regularly test and maintain compatibility

Produce a regularly updated compatibility policy that details support levels, scenarios tested against, and technology used to benefit users.

Success Criterion: Compatibility policy
Establish and maintain a compatibility policy which covers current and obsolete devices and software versions, listing the supported device brands, operating systems, and browsers (including versions). Update this regularly in line with new releases.

Success Criterion: Maintaining compatibility
Avoid planned obsolescence. Strive to maintain compatibility for as long as possible and communicate clearly whether an update is evolutionary, as in large updates that can significantly reduce performance, or corrective, as in smaller updates that fix bugs or improve security.

Success Criterion: Frequent testing
Test performance in various scenarios to ensure compatibility. Testing should cover weak, unstable, restricted, or slow connections, old browsers, and devices older than five years.

Success Criterion: Mobile friendly
Use device-adaptable methods such as responsive design and prototype interfaces to support progressive enhancement and content prioritization.

Success Criterion: Progressive web applications (PWAs)
Use a PWA over a native mobile application if it meets sustainability, interoperability, and compatibility criteria.

Previous

I no longer have access to the previous document. Earlier version: https://w3c.github.io/sustainableweb-wsg/#display-any-variables-that-have-a-negative-impact-on-your-project

Discussion

Clarify

• This would also belong higher up.
• Needs Clarification
• Much of these feels more like a QA task rather than UX
• except the mobile friendly bit
• This may seem pretty minimal when most browsers are chromium based now

Restructure

• Feels very webdev to me ("we don't support IE 5"). A more intentional guideline might be "define the platform / device compatibility - being as inclusive as possible of older browsers and devices" - "do this so you aren't serving high- bandwidth content to low- bandwidth devices, you aren't serving advanced web features to unsupported browesers etc - that would relate this back to the point about not wasting data
• SC (Mobile friendly) merge with 3.13 (Device-adaptable)
• Merge compatibility guidance from 2.29 with 2.2 - Rationale: Both address user environments and platform access. Integrate into a single guideline that focuses on inclusive compatibility and technical constraints. https: / / github.com/ w3c/ sustainableweb-wsg/ issues/ 64
• Maybe move to product. Defining what will be supported (encourage that to be as far as possible) sounds like a product level decision. UX then works with that constraint in mind, no? And dev + QA have to make sure it actually works as defined/ designed

Comments

• Once the WSG is restructured out of role-based, I think this will be fine. I believe this is still a UX responsibility, but many may not understand it as such.

Google sheet of feedback

[fershad]

All in for promoting PWAs over mobile apps, but this SC is very open ended:

Success Criterion: Progressive web applications (PWAs)
Use a PWA over a native mobile application if it meets sustainability, interoperability, and compatibility criteria.

Maybe rather than PWA over native, could we say something like

Provide users with the option to install web applications as a PWA.

That statement can be answered with a "yes/no", while still achieving the same goals as the previous one in my opinion.

[jenstrickland]

Please see this issue, w3c/sustainableweb-wsg#64, with input from @mgifford and @thorstenjonas on consolidating.

[AnneFaubry]

All in for promoting PWAs over mobile apps, but this SC is very open ended:

Success Criterion: Progressive web applications (PWAs)
Use a PWA over a native mobile application if it meets sustainability, interoperability, and compatibility criteria.

Maybe rather than PWA over native, could we say something like

Provide users with the option to install web applications as a PWA.

That statement can be answered with a "yes/no", while still achieving the same goals as the previous one in my opinion.

I wouldn't say that "Provide users with the option to install web applications as a PWA." achieves the same goal. It could encourage a company having a website and a native app to add a functioning PWA instead of replacing their native app by a PWA. This is less environmental friendly if not worse than before.

[AnneFaubry]

Feels very webdev to me ("we don't support IE 5"). A more intentional guideline might be "define the platform / device compatibility - being as inclusive as possible of older browsers and devices" - "do this so you aren't serving high- bandwidth content to low- bandwidth devices, you aren't serving advanced web features to unsupported browesers etc - that would relate this back to the point about not wasting data

There was a european project law stating something like: support smartphones at least 7 years old and computers at least 10 years old. Therefore we don't have to update the OS or browsers supported versions every year.
Interesting phrasing from GreenIT's guidelines on this topic: https://rweb.greenit.fr/en/fiches/RWEB_0019-prefer-pwa-over-native-mobile-applications-that-are-similar-to-the-website

[TzviyaSiegman]

This seems like the difference between maintenance and starting new. @AnneFaubry points out that the majority of people looking at WSG are going to be people with existing apps/websites.

[jenstrickland]

There is an opportunity to consolidate this into a single guideline with #160 . On that ticket I made the case for keeping these in UX. I notice a lot of UX folks are unfamiliar with UX QA -- it is part of some teams' and some seasoned UXer processes. It is important that UX continues to measure, monitor, and improve the UX performance, rather than just shipping and leaving it to others.

[jenstrickland]

After reviewing the multiple guidelines and the number of SC for each, I don't think they can be consolidated.

I guess the main point is that the testing / QAing / auditing / measuring / monitoring is very much a UX responsibility.

[codewordcreative]

I agree with @jenstrickland - it is important we don't muddy the waters with ownership, i.e. ensuring someone takes responsibility for these aspects long term.

[jenstrickland]

Notes: I see an opportunity to consolidate this with Measure and test for performance, or Audit and test for bugs or issues requiring resolution, or other guidelines (especially Frequent testing). It would require focused attention to streamline the guidelines and SC, removing redundancies. This is beyond the scope of something I feel appropriate about doing alone. So, for now, I am incorporating the feedback above using the existing guideline and SC.

I also tried to locate the law @AnneFaubry referenced, thinking that we could consider aligning our time suggestion in Frequent testing, but I couldn't find it.

📣 Please review and provide input using the reactions. 👍 if approval, 👎 if not, and be sure to provide comments before Dec. 3rd.

--

Proposed Guideline: 2.29 Regularly test and maintain compatibility

Produce a regularly updated compatibility policy that details support levels, scenarios tested against, and technology used to benefit users.

Success Criterion: Compatibility policy

Establish and maintain a compatibility policy which covers current and obsolete devices and software versions, listing the supported device brands, operating systems, and browsers (including versions). Update this regularly in line with new releases.

Success Criterion: Maintaining compatibility

Avoid planned obsolescence. Strive to maintain compatibility for as long as possible and communicate clearly whether an update is evolutionary, as in large updates that can significantly reduce performance, or corrective, as in smaller updates that fix bugs or improve security.

Success Criterion: Frequent testing

Test performance in various scenarios to ensure compatibility. Testing should cover weak, unstable, restricted, or slow connections, old browsers, and devices older than five years.

Success Criterion: Mobile friendly

Use device-adaptable methods such as responsive design and prototype interfaces to support progressive enhancement and content prioritization.

Success Criterion: Progressive web applications (PWAs)

Use a PWA over a native mobile application if it meets sustainability, interoperability, and compatibility criteria.