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 Friday, 4 March 2011 17:18:30 UTC