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

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

Received on Monday, 19 July 2010 07:30:48 UTC