RE: ATAG2 B.2.1.1 proposal

Hi Alessandro,

I tried adding it, but it requires the extra explanation that sometimes restriction is good for accessibility. Also, strictly speaking, the SC is not applicable rather than passed if the tool allows unrestricted editing. Perhaps this can be prominent in the "intent"?

Updated proposal (I added "that authors can specify" to more clearly differentiate it from the auto-generation SCs that have different requirements):
-----

B.2.1.1 Accessible Content Possible (WCAG): If the *authoring tool* places *restrictions* on the *web content* that authors can specify, then those restrictions do not prevent WCAG 2.0 success criteria from being met. (WCAG 2.0)
- The WCAG 2.0 Level A success criteria can be met (Level A); or
- The WCAG 2.0 Level A and Level AA success criteria can be met (Level AA); or
- The WCAG 2.0 Level A, Level AA, and Level AAA success criteria can be met (Level AAA).

DEFN: restricted web content authoring
When the web content that authors can specify with an authoring tool either must include or must not include certain content (e.g. elements, attributes, widgets, etc). Many authoring tools restrict authoring in some way, which can either benefit accessibility (e.g., if text alternatives for non-text content are required) or detract from accessibility (e.g. if attributes for defining text alternatives are not available). In contrast, authoring tools that allow unrestricted web content authoring do not require any particular content to be included or not included (e.g. many *source editing-views*).

--

Intent of Success Criterion B.2.1.1:
The intent of this success criterion is to ensure that authors who have the motivation and knowledge to create accessible web content using an authoring tool are not prevented from doing so by restrictions in the actions that the authoring tool allows them to perform. The subsequent success criteria in Part B will build on this minimal requirement. 

Note that the term "restricted" is not intended to have any negative connotation. Authoring tools usually restrict web content authoring in order to simplify the production of content that is in fact complex and technical. The accessibility implications of the restrictions may be positive or negative and need to be considered case by case:

Examples of unrestricted authoring:
(a) source code editor: authors can type whatever they like "<img src="..." alt="..." longdesc="..." />
(b) WYSIWYG editor for HTML4: the "Insert Image" dialog includes all of the HTML4 attributes for <img>

Examples of restricted authoring that meets WCAG 2.0:
(c) WYSIWYG editor for HTML4: the "Insert Image" dialog includes just some of the HTML4 attributes for <img>, but "alt" and "longdesc" are included in the subset.
(d) CMS: authors can only add images that they have previously uploaded to their "Asset Manager". While alt-text and long description do not appear as options when they choose images from the "Asset Manager" to include on a page, they can add/edit these values at any time within the "Asset Manager".
 
Examples of restricted authoring that fails WCAG 2.0:
(e) WYSIWYG editor for HTML4: the "Insert Image" dialog has only one field "src". There is no possible way to add other attribute values, including for the "alt" and "longdesc" attributes.
(f) CMS: to be saved, each page of content must have a main title, but when the author provides text for the title it is marked up with presentation markup rather than appropriate header markup.

See Also: Unrestricted authoring tools entails less author guidance and therefore may allow for the introduction of more accessibility problems than authoring tools with restrictions that encourage accessibility. ATAG 2.0 address this issue with other success criteria, including B.3.1.1 Checking Assistance (WCAG), which requires an accessibility checking feature.

See also: Restrictions on authors may also be related to automatically generated content. ATAG 2.0 addresses the accessibility of automatically generated content in Guideline B.1.1: Ensure automatically specified content is accessible.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

--

Examples of Success Criterion B.2.1.1:
    * Accessible workflow exists: An authoring tool is designed such that accessible web content (in this case to WCAG 2.0 Level A) will result if authors do all of the following:
          o turn on all features that support the production of accessible content; and
          o correctly follow all prompts by features that support the production of accessible content; and
          o uses the accessibility checker, including a final check prior to publishing; and
          o correctly perform any manual checks suggested by the accessibility checker; and
          o correctly repair all of the automatically, semi-automatically or manually identified web content accessibility problems using the automated, semi-automated and manual repair assistance that the authoring tool provides.
    * Source content editing-view: An authoring tool is designed around a source editing-view, allowing motivated and knowledgeable authors to control every detail of the content produced, including following accessible authoring practices.








-- 
(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://inclusivedesign.ca/
Faculty of Design | OCAD University


> -----Original Message-----
> From: Alessandro Miele [mailto:alessandro.miele@standardware.net]
> Sent: March 7, 2011 3:42 AM
> To: Richards, Jan; AUWG (w3c-wai-au@w3.org)
> Subject: RE: B.2.1.1 proposal
> 
> Hi Jan,
> 
> I agree with you, I didn't point out that SC B.3.1.1 is what I tried to
> emphasize.
> 
> So my last proposal is to just put a "warning" reference to the B.3.1.1 in the
> definition of "Restricted web content authoring"
> Something (easy) to express the concept like this (?):
>  [...]
> - Authoring tools that do not place restrictions [...] will automatically pass
> this *(See B.3.1.1. for important info)*
> [...]
> 
> Have a nice day,
> Alessandro
> 
> -----Original Message-----
> From: Richards, Jan [mailto:jrichards@ocad.ca]
> Sent: lunedì 7 marzo 2011 04:16
> To: Alessandro Miele; AUWG (w3c-wai-au@w3.org)
> Subject: RE: B.2.1.1 proposal
> 
> Hi Alessandro,
> 
> Thanks for pointing out that I missed longdesc in (d).
> 
> Re: Notification to the user. I think that this is well handled by "B.3.1.1
> Checking Assistance (WCAG)". The SC in question (B.2.1.1) is intended to
> ensure that authoring tools don't absolutely prevent accessibility.
> 
> Cheers,
> Jan
> 
> 
> --
> (Mr) Jan Richards, M.Sc.
> jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844 Inclusive
> Design Research Centre (IDRC) | http://inclusivedesign.ca/ Faculty of Design |
> OCAD University
> 
> 
> > -----Original Message-----
> > From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org] On Behalf
> > Of Alessandro Miele
> > Sent: March 6, 2011 1:15 PM
> > To: AUWG (w3c-wai-au@w3.org)
> > Subject: RE: B.2.1.1 proposal
> >
> > Hi Jan,
> > it's really clear the concept of restricted/unrestricted. Thank you for the
> > explanation.
> > Anyway I'm still thinking about this:
> >
> > at the second-d) point the tool misses the feature to add the "alt " or
> > "longdesc" fields, so definitely the tool doesn't pass the SC because it
> > doesn't let the user to edit the content in a way that the final output will
> > be in compliance with WCAG 2.0.
> >
> > Otherwise, in the a) point, the tool lets the author to edit raw code and
> it's
> > up to him to check if the output meets the WCAG 2.0; in this case the tool
> > passes the SC because it is "unrestricted", but Imho I believe that the
> author
> > should be aware that the tool, even if it has been claimed as a "tool that
> > generate compliant output", in this case is in "unrestricted mode" so it is
> > not really true that the output will be really in compliance whit WCAG 2.0
> > rules.
> >
> > The same could happen if, e.g. in the first-d) case, the CMS lets author to
> > edit the raw code switching the tool to the "unrestricted mode": the author
> > should be informed that he is editing the code at his own risk because he
> > could make some mistakes and thus the final output could not be in
> compliance
> > with WCAG 2.0.
> >
> > So my question is: should the author be informed regarding the
> > restricted/unrestricted state of the authoring tool and all of its
> > consequences?
> >
> > have a nice day,
> > Alessandro
> >
> > -----Original Message-----
> > From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org] On Behalf
> > Of Richards, Jan
> > Sent: venerdì 4 marzo 2011 18:18
> > To: AUWG
> > Subject: RE: B.2.1.1 proposal
> >
> > Hi Alessandro,
> >
> > I think it does make sense to explain restricted/unrestricted a bit more.
> > Taking images as the easiest example:
> >
> > Examples of Unrestricted:
> > (a) in a source code editor I can type whatever I like "<img src="..."
> > alt="..." longdesc="..." myattrib="" />
> > (b) in a WYSIWYG editor for HTML4.01, the "Insert Image" dialog includes ALL
> > of the HTML4.01 attributes for <img>.
> >
> > Examples of Restricted but meets WCAG 2.0:
> > (c) in a WYSIWYG editor for HTML4.01, the "Insert Image" dialog includes
> just
> > some of the HTML4.01 attributes for <img> but "alt" and "longdesc" are
> > included in the subset.
> > (d) in a CMS, I can ONLY add images that I have previously uploaded to my
> > "Asset Manager". While alt-text does not appear as an option when choose
> > images from the "Asset Manager" to include on a page, I can add/edit the alt
> > text at any time within the " Asset Manager".
> >
> > Examples of Restricted but FAILS WCAG 2.0:
> > (d) in a WYSIWYG editor for HTML4.01, the "Insert Image" dialog has only one
> > field "src". There is no possible way to add "alt" and "longdesc" attribute
> > values using the tool.
> >
> > Cheers,
> > Jan
> >
> >
> > --
> > (Mr) Jan Richards, M.Sc.
> > jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844 Inclusive
> > Design Research Centre (IDRC) | http://inclusivedesign.ca/ Faculty of Design
> |
> > OCAD University
> >
> >
> > > -----Original Message-----
> > > From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org] On
> Behalf
> > > Of Richards, Jan
> > > Sent: March 4, 2011 11:32 AM
> > > To: AUWG
> > > Subject: FW: B.2.1.1 proposal
> > >
> > > Forwarded message from Alessandro M. (while Jeanne tries to get his email
> > > address accepted by the list):
> > >
> > > -----Original Message-----
> > > From: Alessandro Miele [mailto:alessandro.miele@standardware.net]
> > > Sent: March 4, 2011 11:31 AM
> > > To: Richards, Jan
> > > Subject: RE: B.2.1.1 proposal
> > >
> > > Hi all,
> > >
> > > Following the discussion, I believe that B2.1.1 should remain and that
> > > "restricted web content" should be defined.
> > > Regarding the title of B.2.1.1 "Accessible Content Possible", I think that
> > the
> > > word "Production" as was in the old definition, could be more
> understandable
> > > than "Possible".
> > >
> > > But which could be restrictions?
> > > If I use a CMS that doesn't provide support for inserting movies in a
> > webpage,
> > > but anyway generates output that meet the WCAG SCs, could be this a
> > > restriction example?
> > > But If the tool has the "Unrestricted mode" switched on, then it could let
> > the
> > > author insert the movie anyway without "warranty" on the output, right? In
> > > this case the tool will pass the SC. (?)
> > >
> > > So reporting your definition "When the web content [...] include certain
> > > elements, attributes, widgets, etc." the problem could be to define the
> > > "elements"...
> > >
> > > Maybe we could move the focus of the wording to the concept of
> "Restricted"
> > or
> > > "Unrestricted" mode available on the authoring tool...
> > >
> > > Just some thoughts...
> > >
> > > Cheers,
> > > Alessandro
> > >
> > > -----Original Message-----
> > > From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org] On
> Behalf
> > > Of Richards, Jan
> > > Sent: giovedì 3 marzo 2011 16:12
> > > To: AUWG
> > > Subject: B.2.1.1 proposal
> > >
> > > Hi all,
> > >
> > > Alastair and I have worked on some wording that will hopefully strengthen
> > > B.2.1.1 in a reasonable way:
> > >
> > > B.2.1.1 Accessible Content Possible (WCAG): If the *authoring tool* places
> > > restrictions on the *web content* that can be produced, those restrictions
> > do
> > > not prevent WCAG 2.0 success criteria from being met. (WCAG 2.0)
> > >
> > > - The WCAG 2.0 Level A success criteria can be met (Level A); or
> > >
> > > - The WCAG 2.0 Level A and Level AA success criteria can be met (Level
> AA);
> > or
> > >
> > > - The WCAG 2.0 Level A, Level AA, and Level AAA success criteria can be
> met
> > > (Level AAA).
> > >
> > >
> > >
> > > Alastair and I did not discuss whether restricted needs to be defined, but
> > as
> > > I have been putting this together, I think it does....so here's a start:
> > >
> > > restricted web content authoring
> > > When the web content that authors can produced with an authoring tool
> either
> > > must include or must not include certain elements, attributes, widgets,
> etc.
> > >
> > >
> > > Points to make in the implementing doc:
> > > ---------------------------------------
> > > - As with all ATAG SCs, this SC applies to the tool as a whole, not just
> > parts
> > > of the tool.
> > > - Authoring tools that do not place restrictions or that have unrestricted
> > > modes (e.g., code-level editing views) will automatically pass this.
> > > - Restricted environments are fine, and in many cases they actually
> benefit
> > > accessibility, as long as the restrictions don't prevent applicable WCAG
> 2.0
> > > SCs from being met.
> > >
> > >
> > > Thoughts?
> > >
> > > Cheers,
> > > Jan
> > >
> >
> >

Received on Monday, 7 March 2011 16:31:02 UTC