Re: Audience Based Validator User Interface (ISSUE-206)

Hi Laura,

 "HTML5 authoring tools MUST
> NOT emit documents that do not conform to HTML5" to "HTML5 authoring
> tools SHOULD NOT emit documents that do not conform to HTML5". The
> allowed exceptions would be content author supplied attribute values,
> which are engineers control.


I think this would be a good change, regardless of issue 206, I do not
believe that this must level requirement is realistic or practical.
Any editing tool other than in the most controlled of environments can emit
non conforming documents. I would go so far as to say there is no editing
tool which  can guarantee that the output will always be conforming.

regards
SteveF

On 4 August 2012 21:03, Laura Carlson <laura.lee.carlson@gmail.com> wrote:

> Hi Henri,
>
> You wrote [1]:
> > I don't really see the point of Laura's proposal.
>
> As I read it, the point of Ted's proposal is to give engineers of
> large web applications precedent over authors trying to do the right
> thing and end-user requirements for accessible web content. That is
> backward. It is also contrary to the priority of constituencies design
> principle. The point of my proposal is to rectify that matter and set
> things in proper order. As the W3C Validator documentation states,
> "Validating Web documents is an important step which can dramatically
> help improving and ensuring their quality..." [2]. It provides a
> teachable moment, to whit: "Validation helps teach good practices"
> [3]. Authors who are tring to catch errors should by default continue
> to receive errors as they always have to help them in that task.
> Hiding or suppressing errors from authors by default is counter
> productive as it defeats their whole effort.
>
> As I just said to Mike in the first email in this thread, The crux of
> the matter has always been that two validator user groups 1.) authors
> 2.) engineers of large web applications have different goals. Good
> authors want to catch errors so that they can fix them. Engineers of
> large Web applications want to suppress errors that are beyond their
> control so it doesn't reflect poorly on their product.
>
> After thinking hard about this issue since 2008, I am wondering if an
> audience based validator user interface might have the possibility to
> satisfy both constituencies. Check my email to Mike and the audience
> mockup at:
> http://www.d.umn.edu/~lcarlson/research/206/byaudience.html
> What do you think, Henri?
>
> Another important aim of my proposal is to try to help improve
> accessibility in the future. Check:
> http://ur1.ca/9vryd
> Thanks to Steve I just added more info to that section.
>
> The only other way I can think of to solve ISSUE-206 besides creating
> an incomplete attribute and the audience based UI is to change the
> restriction on HTML5 authoring tools from "HTML5 authoring tools MUST
> NOT emit documents that do not conform to HTML5" to "HTML5 authoring
> tools SHOULD NOT emit documents that do not conform to HTML5". The
> allowed exceptions would be content author supplied attribute values,
> which are engineers control.
>
> Best Regards,
> Laura
> [1] http://lists.w3.org/Archives/Public/public-html/2012Aug/0031.html
> [2] http://validator.w3.org/about.html
> [3] http://validator.w3.org/docs/why.html#learning
>
>
> --
> Laura L. Carlson
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html