RE: User-adaptations in SCs



> -----Original Message-----
> From: Alastair Campbell [mailto:acampbell@nomensa.com]
> Sent: Wednesday, February 15, 2017 7:30 AM
> You made a comment on the survey that I wanted to pick up on list, I hope that’s
> ok to do? It could impact other SCs as well, so I think it’s worth discussing on-
> list.

[Jason] I agree.
>
> The original SC was written in that way:
> > > RE: "Adaptable presentation: Overriding the font-family, colors or spacing
> used on a web page does not cause loss of content or functionality."
>
> But on the list (23rd Jan) we had a comments from Gregg such as:
> > I dont think the author has any control of this.  You are asking the author to be
> responsible for what someone else does — without saying what that person
> might do.
> …
> > it doesn't say HOW the user will change it.   It is like saying to the builder —
> your house must stand no matter what the homeowner does to modify the
> structure after you they buy it.    You can do a lot to make a house modifiable
> but you can’t be charged with ensuring that it will stay functional no matter
> what the user does.
>
> So the explicit thing we had to do in order to progress was make it testable
> within the SC text. The values were selected to provide a baseline for testing,
> rather than be representative of what users would pick as such.  The idea is that
> testing that baseline will highlight issues that would come up for other values (up
> to a reasonable point).
>
> On the face of it you are asking us (David is SC manager) to undo that change,
> but I think it also highlights that we are trying to do something new in WCAG 2.1,
> which is to address the user-need to adapt web pages more than the site
> provides for.
[Jason] Yes, to be clear, I am asking you to undo that change, and I'm trying to push back against the original objection which led you down the proposed path, as I don't find it persuasive.

The ability to withstand changes in font, colour, spacing etc., without loss of information or functionality, is clearly a property of the content that it either has or does not have. In technical terms, it's often referred to as a "dispositional property", as in the brittleness of glass, which can be understood in terms of how it would behave it subjected to certain forces. If you can show that there are good tests for determining whether the content has this property or not, and that there are ways in which the content author can design their Web pages accordingly, then the original requirement is in fact testable, and I think you should state it as the SC (adding a note in the Guidelines or techniques about the quick and effective heuristics for assessing it if you wish). If you don't have effective means of testing content for satisfaction of the original requirement, can you state ranges over which the content needs to be transformable for which you do have effective evaluation procedures? The current proposal doesn't state limits, ranges of values, etc. at all.

My main concerns with the proposed approach are (1) that it leaves the underlying purpose opaque to readers of the Guidelines, (2) that it prevents content authors from understanding and applying the underlying purpose rather than the narrow testing requirement stated in the proposed SC, and (3) if the testing requirement doesn't prove to be robust - if it can pass in ways that fail to achieve the actual purpose of allowing the necessary user adaptation - then it won't adequately address the accessibility need which it is designed to support.


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________

Received on Wednesday, 15 February 2017 13:37:34 UTC