FW: Discussion on SC numbering

Hi everyone,

Resending this on Josh’s request.

In addition, in the call I suggested that we should probably proceed as though we are only adding not modifying and accept overlap for the FPWD. Then we *should* carefully modify current requirements to reduce overlap.

I also asked a question from a previous email: I'm also curious if anyone knows of another guidelines-type standard that has added a significant number of requirements in a later version, how did they handle numbering or re-wording of previous requirements?

On 23/12/2016, 11:14, Alastair Campbell wrote:

Gregg wrote:
>  What I was referring to though — was that we ALSO have some that purposely overlap.   Like    Don’t do this except — and  Don’t do this ever  (at two different levels).      We have a number of places where we have multiple SC that overlap — with SC at different levels increasing the requirement.

Yes – which makes sense, and was something you could do in 2.0 because you could manipulate both SCs at the same time.

In a situation where we cannot modify the current ones at all, it is not possible to add related requirements without causing overlap/confusion.

To take a really simple case, WCAG 2.0 has one AA contrast SC:
“1.4.3 Contrast (Minimum): The visual presentation of text and images of text…” – which only applies to text, and I think all the docs support that approach.

Assuming the new contrast SCs for graphics & interactive elements pass muster, could we not rename the current one to “Text contrast (Minimum)”?

Taking a more complex example:
https://github.com/w3c/wcag21/issues/51


Assuming for sake of argument that we agree the level should be raised from AAA to AA (e.g. new evidence of user-need and/or it would now be easier to implement), there are also proposed changes within the SC:

---------------
2. Width is no more than 80 characters or glyphs [del](40 if CJK)[/del] [ins]for Latin and Semitic based languages; or 40 for Chinese, Japanese, and Korean; or can be selected by the user[/ins].

3. Text is not fully justified (aligned to both the left and the right margins), [ins] or justification can be set by the user[/ins].

5. Text can be resized, without assistive technology, up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.

[ins]6. Increased line and border spacing can be added around blocks of text and objects, such that they can be increased up to 200% without loss of content or functionality.[/ins]
---------------

The changes in points 2 & 3 appear minor, point 5 is in the existing SC but completely redundant with the new Resize content SC, and point 6 would require another technique and addition to the understanding doc.

I can’t see how you would make those changes into a new SC without it being too specific? (I.e. criticised as just a technique).

For those people saying we shouldn’t touch the existing SCs, are you suggesting we reject all modifications?

Even if the response is: “we should take the changes and make new SCs”, I don’t think those new SCs would be able to meet the criteria, so the effect would be to reject most or all modifications.

Cheers,

-Alastair

Received on Tuesday, 3 January 2017 17:02:22 UTC