Consensus Tally for Adapting Text SC Text

From WCAG WG

This page tracks results for Proposal A and B as described in Laura's March 27, 2017 GitHub comment.

We have had considerable discussion on the Adapting Text SC, Issue 78. Currently we are attempting to ascertain if we can get consensus on one point. It is whether to use "A mechanism is available" language in the SC text or not. Two proposals are under consideration.

In a GitHub comment on Issue 78, please let us know if you cannot live with: Proposal A or B. If you have a preference please let us know that too.

Can't Live with Proposal A

  1. @alastc (Alastair) "I can live with A if we beef up the note a bit, how about: "NOTE: The usual mechanism is by a user style sheet or user plugin for the browser, so for mark-up languages the authoring requirement is to ensure adaption works for the criteria specified." Source: GitHub comment 289571266

Can't Live with Proposal B

  1. @DavidMacDonald: "without hard metrics, I can't live with B, for reasons mentioned. I can explain this on the call. I will bring in the opinion of a lawyer who was a legal draftsman for the Gov of Canada legislation." Source: GitHub comment 289356511 (However, proposal A is ok with me.)

Prefer Proposal A

  1. @WayneEDick: "Leave 'a mechanism' language. 1.) The mechanism concept is well defined in 2.0. Many SCs in 2.0 require developer re-coding. 2.) HTML and PDF support these mechanisms at the user agent level if pages are coded correctly. Thus, a mechanism is present for good code. 3.) If an author does not follow conventions that support independence of content and presentation, then the author should be required to produce a mechanism. That too is consistent with WCAG 2.0 because we do not restrict the author to conforming in just one way. This protects author freedom." Source: GitHub comment 289564504
  2. @jasonjgw (Jason White): "I would support option A with a note along the lines suggested." Source: GitHub comment 289609195
  3. @awkawk (Andrew): "I agree with Gregg on the note. The note is not acceptable to me - I don't think that it is needed since we have the understanding document. I prefer "A" but we need to include "essential" in the SC like this: "A mechanism is available to override the following text styles of the page, with no loss of @@essential@@ content or functionality." Source: GitHub comment 289792275

Prefer Proposal B

  1. @mraccess77 (aka Jon Avila): "I like B the best." Source: GitHub comment 289447295

Related Comments

  1. @jasonjgw (Jason White): "Proposal A has the advantage (to the user) that the author provides the mechanism if there are no user agents or assistive technologies available to do it. However, it seems to me that mechanisms are available already for all of the currently significant technologies (HTML, PDF, etc.), though admittedly not for all devices/environments, and so the author really shouldn't have to intervene to provide the mechanism. The only author responsibility is to ensure that their content incurs no loss when the changes are introduced by the UA. Thus I think Proposal B is fine. Another option would be to introduce Proposal B at level A or AA, and proposal A at level AAA." Source: GitHub comment 289516216
  2. @GreggVan (Gregg Vanderheiden): "these [Note 2 in the SC] look like Understanding WCAG comments — or they look like techniques. this should not be in the guidelines doc itself." Source: GitHub comment 289767649
Retrieved from "https://www.w3.org/WAI/GL/wiki/index.php?title=Consensus_Tally_for_Adapting_Text_SC_Text&oldid=7675"