W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 2011

RE: B.2.1.1 proposal

From: Alessandro Miele <alessandro.miele@standardware.net>
Date: Sun, 6 Mar 2011 18:15:01 +0000
To: "AUWG (w3c-wai-au@w3.org)" <w3c-wai-au@w3.org>
Message-ID: <86CDCCD0E62E544BB01AC6F75136D5B20723FE95@QG-Server2.standardware.net>
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 Sunday, 6 March 2011 18:14:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 March 2011 18:14:57 GMT