Re: Discussion on SC numbering

On 21/12/2016 11:28, Alastair Campbell wrote:

> The main issues that jumped out at me is not the numbering, but issues
> that come from the “Not modifying existing SC” assumption, which has two
> impacts:
[...]
> I agree that SCs should overlap as little as possible, overlap makes
> testing harder and the communication of results /much/ harder. However,
> we can’t apply that SC requirement without editing current SCs.
>
> I think this is the most difficult issue to deal with, but it is more
> important and fundamental than which numbering scheme is used.
>
> My opinion is that it is more important for WCAG 2.1 to be a coherent
> and understandable document than maintaining the exact wording of
> existing SCs. I agree that it should be backwards compatible, but we can
> modify (increase) current SCs and maintain backwards compatibility, and
> the change can be managed with an associated document that outlines the
> changes.

Strongly agree with Alastair here, on all counts.


> On the numbering scheme, a few things became apparent:
>
>
>
> *Model 1, 4^th level numbering*: Having an additional number (e.g.
> 1.4.5.1) makes that SC appear to be a sub-SC underneath its parent, even
> if it is unrelated. For example, having the enhanced “Visual
> Presentation” under “Images of Text”.
>
> *Model 2, append-only*: Putting all the new SCs at the end means that
> you lose the association between similar SCs. For example, you have the
> old Resize text, and then the new Resize content way underneath, which
> is actually a stronger requirement. Odd, and I think this hurts
> understandability the most.
>
> *Model 3, append numbers but maintain topical ordering: *Maintains a
> good order and association, it is just odd to have 1.4.11 following
> 1.4.3. Assuming we don’t use model 6, this would be my preference.
>
> *Model 4, level markers*: similar to model 3 but I think the “1.4.AA.3”
> looks odd.
>
> *Model 5, renumbering:*Avoids the problems of models 1-4, but for
> experienced testers/consultants this would be confusing for years.
>
> *Model 6, remove numbers*: This (now) makes the most sense to me,
> especially if a WCAG 2.2 is possible. Any of the problems above would be
> magnified if more SCs are slotted in later for a 2.2. It means we can
> keep a good order, with the A/AA/AAA groupings and
>
> I also put together an example based on model 6, but allowing for
> updating the 2.0 SCs:
>
> https://alastairc.ac/tests/wcag21-examples/wcag21-model6b.html

The one problem with Model 6 is that it removes the ability to concisely 
reference SCs. You'll always end up having to put in the full (bold) 
shortname, and for easy orientation (so somebody can actually find it in 
a lengthy document, without having to do a search) probably also 
indicate the guideline. So you'd say "such and such fails WCAG 2.0 
Guideline 1.4 Low or No Background Audio" (compared to, say, "this fails 
WCAG 2.0 SC 1.4.7").

I'd favor organising all the SCs in the most logical grouping/manner, 
and at the end doing a consistent numbering in the same vein as WCAG 
2.0. Yes, this will result in SCs from WCAG 2.0 not having the same 
number in WCAG 2.1. Yes some people will get confused by this. But 
again, providing a simple overview/mapping document that shows "These 
WCAG 2.0 SCs are now renumbered/modified in WCAG 2.1" shouldn't be 
complex or onerous to create and for authors/testers to reference (but 
of course that's personal opinion).

P
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Wednesday, 21 December 2016 12:12:00 UTC