search

w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
140 stars 55 forks source link

Can we state that cumulative effects of success criteria are applicable for AAA? #898

Closed cwadamsoforacle closed 6 years ago

cwadamsoforacle commented 6 years ago

There's been conversations about the cumulative effects of various success criteria:

There have been concerns that the permutations required to test the combinations of the cumulative effects would be prohibitive. My suggestion/question is whether or not we can advocate for the cumulative effective of multiple success criteria, but stipulate that this is required for AAA conformance (even if the underlying criteria are A or AA).

goodwitch commented 6 years ago

I think this idea has merit. As an accessibility advocate, I want these to be cumulative, because it will help real people. But I'm super worried about the increased cost/effort of testing...from a world wide perspective.

Testing at each breakpoint (as defined by the developers via the code) is totally within reason (and I believe must be done). Testing at every single pixel change in viewport width??? Ummmmm exponentially expensive. I'm worried that we won't get consistent testing results (even between experts). And that leads to the question...how will developers ever know if their sites are compliant?

awkawk commented 6 years ago

closing for future consideration

WayneEDick commented 6 years ago

All of us who have tested every browser with every screen reader on a range of ARIA roles knows the difficult of combinatorial test explosion. It is hard work. I would first like to say that this problem is much less difficult than ARIA, browser, screen reader compatibility. The number of tests may be high, but it's a lot smaller that the number of roles times browsers times screen readers. Also, the test are simpler.

In addition, there is extremely good reason for satisfaction of the SC's in multiple contexts. 1) People's visual acuity usually gets worse as the day proceeds. 2) Different pages read better in different orientations at different sizes. 3) The cumulative effects impact users as well as testers.

1) It is always best to use as small print with as little spacing as possible to improve the number of words per page. That is very important in the large print world. Remember, we are talking about an upper limit of 400% enlargement (16 CSS px at 320 CSS px width). So, space really matters. One may start the day at 300%, go to 350% a little later and then go all the way to 400% later. This may necessitate a change of spacing and orientation. I flip my tablet all the time. 2) A text heavy page may lay out better in portrait mode, but a page with tables, images and multi-level lists might fit better in landscape. 3) The combination of enlargement with reflow and text spacing has a major impact on the users choices. A text with good spacing can usually be read at considerable less enlargement. Applying this to 1), a person may start with smaller print (300%) and less letter spacing. As the day proceeds the letter and line spacing are increased. Later the font-size goes up, but line spacing is pinched a little. Finally, you wind up at 400%, max letter spacing and more line spacing. Applying 2), one may shrink the page and change orientation to fit an entire table width on screen.

Finally, let's do a little combinatorics. Most pages I've seen don't have more than about 4 breakpoints. Let's add one to that for robustness, 5. Now, font sizes that must be tested are functionally determined by breakpoints. So, font size does not add to the count. Finally there is letter, line, word and paragraph spacing. But we only need to text the max values. There are two orientations. So, I get 5x2 texts. 10 simple tests is not too difficult.

Cheers, Wayne

On Thu, May 3, 2018 at 10:06 AM Glenda Sims notifications@github.com wrote:

I think this idea has merit. As an accessibility advocate, I want these to be cumulative, because it will help real people. But I'm super worried about the increased cost/effort of testing...from a world wide perspective.

Testing at each breakpoint (as defined by the developers via the code) is totally within reason (and I believe must be done). Testing at every single pixel change in viewport width??? Ummmmm exponentially expensive. I'm worried that we won't get consistent testing results (even between experts). And that leads to the question...how will developers ever know if their sites are compliant?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/898#issuecomment-386366637, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF9YfO21xHMGjKyvZN-ls5WRredASks5tuzkkgaJpZM4TxcXP .