Re: comments on 'private use' section of proposal - Sanity check

hi benjamin,

'accessibility supported' does not depend on the abilities of the audience
it depends upon the technology available to the audience.

The 'accessibility supported' concept does not allow an img not to have a
text alternative for example, but may allow the use of aria-labelledby (for
example) to be used as a method for providing a text alternative if the
target audience is provided with the technology which supports
aria-labelledby.

This is a major difference.

>* In a validator UI most authors will never see, for the subset of
authoring tools which do not insert "alt=''" (disguising missing text
equivalents and inhibiting >user agent repairs).
why will most authors never see a validator UI? many html editing tools have
conformance checkers bulit in.

>I think if Outlook warned about missing text alternatives, that would do a
lot more to prevent blind colleagues receiving HTML emails at work with
missing text >alternatives

What you describe above is an instance of conformance checking UI: Outlook
providing a warning when alt is omitted.

>At any rate, there's a direct conflict between requiring conforming HTML
documents to include text alternatives *and* requiring authoring tools to
generate >conforming documents, so long as we accept tools will (should?)
insert new images into documents, then publish those documents even when
they are >missing text alternatives. They are both good principles, but one
of them has to bend.
 the issue lies with
>requiring authoring tools to generate conforming documents

not with requiring a text alternative (through conforming means)

Can you name any tool that will not publish a document unless it conforms?
It is impossible as HTML5 provides a plethora of non machine checkable
conformance criteria.

Why is it OK to allow non-conforming documents to be published if the intent
of the author cannot be determined? The intent of the author can NEVER be
known by the tool.

For example, I want to publish a document to test the display of an img in
browsers (
http://www.paciellogroup.com/blog/misc/HTML5/alt-tests/alt-examples.html) when
the src path is broken, are you saying that authoring tools must not be
allowed to publish this document?

regards
stevef

On 19 July 2010 09:30, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>wrote:

> On 18 Jul 2010, at 18:18, Steven Faulkner wrote:
> > What this means is that a document can be both conforming and non
> conforming depending on who access it.
>
> Not who /can/ access it, but who the intended audience is.
>
> > Example: if I publish this document and allow a person i know can view
> the image to access the document, then its conforming, if I then allow a
> person I know cannot view the image, it then becomes non conforming.
>
> If you allow it, then you would have changed the intended audience.
>
> Is intended audience really so strange a factor in document conformance?
>
> As I understand it, WCAG2 document conformance can vary depending on the
> audience of the document, because what constitutes "accessibility supported"
> technology varies depending on whether "The content is available in a closed
> environment, such as a university or corporate network, where the user agent
> required by the technology and used by the organization is also
> accessibility supported".
>
> http://www.w3.org/TR/WCAG20/#accessibility-supporteddef
>
> So if you publish a document within such an environment, then later decide
> to publish the document in another environment where different user agents
> are available, the WCAG2 conformance status may change.
>
> WCAG2's distinction between different levels of conformance, "[i]n order to
> meet the needs of different groups and different situations", also addresses
> differing target audiences, to some extent. See for example:
>
> http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1798
>
> Similarly, the levels of conformance are intended to address differing
> author skillsets:
>
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head
>
> In theory, I guess we could have (roughly speaking):
>
> 1. Level One Conforming HTML documents (parseable documents) where the
> syntax conforms.
>
> 2. Level Two Conforming HTML documents (meaningful documents) where the
> semantics conform and text alternatives are provided.
>
> But this is really only a different formalism to what we already have:
>
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#guidance-for-conformance-checkers
>
> Perhaps (?) the core practical issue in this discussion is where the better
> "teachable moment" is:
>
>   * In a validator UI most authors will never see, for the subset of
> authoring tools which do not insert "alt=''" (disguising missing text
> equivalents and inhibiting user agent repairs).
>   * In the authoring tool UIs themselves.
>
> I think if Outlook warned about missing text alternatives, that would do a
> lot more to prevent blind colleagues receiving HTML emails at work with
> missing text alternatives (a problem I've witnessed way too many times) than
> requiring missing "alt" to throw an error in HTML validators of which the
> authors are blissfully unaware. Judging from HTML4, it doesn't seem like
> required-"alt" causes email client UIs to warn about missing text
> alternatives, however much we wish it. Section 508-style legal requirements
> that email clients implement ATAG2 might do it - but that doesn't require
> HTML document conformance changes.
>
> At any rate, there's a direct conflict between requiring conforming HTML
> documents to include text alternatives *and* requiring authoring tools to
> generate conforming documents, so long as we accept tools will (should?)
> insert new images into documents, then publish those documents even when
> they are missing text alternatives. They are both good principles, but one
> of them has to bend.
>
> --
> Benjamin Hawkes-Lewis




-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html