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 03:16:36 UTC