[wcag-3.0] Gray-box testing

Dear All, 

I really applaud the direction of travel WCAG 3.0 is taking. It reminds me of gray-box testing; essentially a testing method that falls between white box and black box testing to help identify defects in applications.  In gray-box testing, as you may know, testers can access the rendered UI and have proxy information about the system's internal workings (in this case, perhaps provided through the DOM or Accessibility Tree), but they cannot see the actual build code of the component being tested. The major benefit from this approach is that a test team can undertake an assessment without the need to question developers - so the assessment is discrete. 

Almost all of the WCAG 3.0 Outcomes appear to be specified in terms of a gray-box testing approach, for example, "Audio shifting designed to create a perception of motion is avoided; or can be paused or prevented”.  I say almost all as I have spotted a couple of outcomes which break with this concept:

1) AI editable: Auto generated text descriptions are editable by content creator.
2) Identify autogenerated text: Auto generated text alternatives are identified.

The issue with both of these is that from looking at the DOM or Accessibility Tree alone a test team could not say if text descriptions have been generated; and would not be able to say if a content creator was able to edit them.  They would be forced to talk with the developers.

Thinking about these two outcomes, I would also question why the use of AI text descriptions is an accessibility issue in itself; when surely it is only the quality of the text description which is impacting (and nicely caught under other outcomes).

In light of the above, are these two specific outcomes in fact necessary to include in WCAG 3.0?

Very best regards

Alistair 

Alistair Garrison
CEO / Founder Accesseo Limited
United Kingdom

Received on Thursday, 22 August 2024 12:39:37 UTC