RE: Outcomes or Requirements

Gregg,

I think as a group we were leaning towards outcomes but have not formally made a decision. Thank you for queuing it back up.

Kind regards,

Rachael

From: Gregg Vanderheiden RTF <gregg@raisingthefloor.org>
Sent: Thursday, September 26, 2024 1:35 PM
To: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Subject: Outcomes or Requirements


CAUTION: This email message has been received from an external source. Please use caution when opening attachments, or clicking on links.
A decision we need to make. (unless we already have and we are just not being consistent )



 will we
a) continue to use Outcomes
    or will we
b) go with requirements like many other standards
(including EN 301 549 - which - by the way quotes WCAG by saying
9.1.1.1 Non-text content
Where ICT is or includes a web page, it shall satisfy WCAG 2.2 Success Criterion 1.1.1 Non-text content.


Outcome =  'the following is true'
example -  The keyboard focus must (or shalll) have a sufficient visual indicator.

Requirement = 'something that must be  (or shall be)’  (done?  true)
example -  The keyboard focus must (or shalll) have a sufficient visual indicator.



I prefer keeping with Outcomes

  *   . It is more in keeping with “it is important for the world to be this way” than “you must do this” or even “this must/shall be done.”
  *   It allows for something to be true for a number of reasons, including something the authors do - or, in the future, all browsers do, or AT that everyone has.

But either way — if we are creating guidelines for Web Content — it seems we are creating guidelines for web content creators.   And we need to not create rules that must be true about content where these rules (for content) may not be needed in the future because it will always be true at the user level anyway because of browsers and operating system features.

1 example from the past is SC 4.1.1, which was a requirement on web content that was important ten years ago but has nothing to do with accessibility today because browsers and ATT interact in such a way that this requirement on content creators has no effect on accessibility and is not needed.

An example for the future may be that all browsers ensure that users can adjust the keyboard focus, and it will override anything on the page. If this is a common feature of all browsers (or an option of all browsers), then there would no longer be a need to have a requirement on content authors that this be true of their content.

And then there are all of the ways that AI will change the equation for everything we are doing and allow users to have personalized views of any webpage they go to, addressing all sorts of needs that we have not been able to address to date. This is especially true in areas where different people need the page to be presented in different ways in order for them to use it, and so it is impossible for a content creator to create something that will be right for everyone, but everyone could have the page transformed into a version that fits exactly them.



The trick is to word our provisions such that an author can clearly tell if and when the outcome will be true, regardless of what they do, or that we have test procedures that allow content authors to quickly determine that they have not done anything in their code to prevent this standard feature in the browsers from allowing this outcome to be true for those pages. (Another reason to focus on outcomes rather than musts or shalls.)


 g

PS   does W3C have a policy for its “Recommendations?"