Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Principles P O U R should be referenced sooner than later in WCAG 3.0 #270

Open
spanchang opened this issue Feb 2, 2021 · 7 comments
Open
Labels
internal comment from a participant migration: core Issues that raise core questions that are still open for discussion only response needed issues that should be easy to close, acknowledgement only

Comments

@spanchang
Copy link

The overarching principles P O U work splendidly to cluster guidelines as done in WCAG 2.X. As the "Requirements For Silver" do not document any limitations or de-merits of doing this, it will be beneficial to introduce the principles sooner into WCAG 3.0 framework.
The principles should be regarded as more than a method for merely filtering content of WCAG 3.0. So these should be introduced into early drafts.
The principles are also a good way of introducing new readers to the field of digital accessibility - and contribute to one of the goals for Silver i.e. ease of use / readability / usability.
Thanks,
Sailesh

@jspellman jspellman added status: assigned to subgroup ask subgroup for proposal Subgroup: editors no specific subgroup (default) labels Mar 3, 2021
@jspellman
Copy link
Contributor

Thank you for your comment. Project members are working on your comment. You may see discussion in the comment thread and we may ask for additional information as we work on it. We will mark the official response when we are finished and close the issue.

@LJWatson
Copy link

LJWatson commented Mar 3, 2021

The basic concepts are good, but I do not think we should continue to use POUR in WCAG3.0. The acronym always felt very contrived to me, and besides - the words themselves are not good examples of plain language.

I also never understood the wisdom of choosing an acronym that, when spoken, was easily confused with the word for low quality.

@bruce-usab
Copy link
Contributor

bruce-usab commented Mar 3, 2021

I don't remember who first proposed POUR, but it did have utility for grouping SC. I also like how it creates a natural hierarchy (e.g., one cannot operate a component if one cannot perceive it, etc.). The one activity (VVSG2) I know of that initially started with the POUR concept for "buckets" of requirements ended up with 15 principles and only one of those (Robust) ended up in the title list.

@spanchang (or anyone else), could you point me to examples of POUR being used elsewhere?

I would call myself as a fan of POUR, but as someone who has had frequent opportunity to introduce people to WCAG2, it has not really resonated with my audience. I am personally comfortable with the planned approach that POUR can be reflected as "tags" in a future iteration of WCAG3.

@spanchang
Copy link
Author

spanchang commented Mar 3, 2021 via email

@LJWatson
Copy link

LJWatson commented Mar 4, 2021

Thanks @spanchang. I agree that a way of organising guidelines is worth considering - I just don't think that the POUR principles are the right way to do it, or at least, the right words to use.

@bruce-usab
Copy link
Contributor

bruce-usab commented Mar 4, 2021

FWIW, one criticism I have heard over the years is that POUR works well enough for organizing SC in a requirements document (i.e. WCAG 2.0), but that POUR does not offer real utility as a way to formulate a test process order. It is quite possible that WCAG3 will be an improvement in that regard!

I recently had opportunity to remind myself that WCAG 1.0 included a view that listed requirements in a reasonable test process sort order:  http://w3.org/TR/WCAG10/checkpoint-list.html

@spanchang
Copy link
Author

Please refer back to the original comment of Dec 2. What is the rationale for doing away with the principles? There will be multiple guidelines and there is agreement they need to be grouped into a coherent framework. Unless there is an acceptable alternative, the four principles should be reinstated. And they are for grouping guidelines, not tests or methods etc.

@jspellman jspellman added only response needed issues that should be easy to close, acknowledgement only internal comment from a participant and removed status: assigned to subgroup ask subgroup for proposal labels Apr 12, 2021
@rachaelbradley rachaelbradley removed the Subgroup: editors no specific subgroup (default) label May 24, 2022
@rachaelbradley rachaelbradley added the migration: core Issues that raise core questions that are still open for discussion label Aug 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal comment from a participant migration: core Issues that raise core questions that are still open for discussion only response needed issues that should be easy to close, acknowledgement only
Projects
None yet
Development

No branches or pull requests

5 participants