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

A sanity check,

.8.1.1.11 An image in an e-mail or private document intended for a specific
person who is known to be able to view images

"*This section does not apply to documents that are publicly accessible, or
whose target audience is not necessarily personally known to the author,
such as documents on a Web site, e-mails sent to public mailing lists, or
software documentation."*
*
*
http://dev.w3.org/html5/spec/embedded-content-1.html#an-image-in-an-e-mail-or-private-document-intended-for-a-specific-person-who-is-known-to-be-able-to-view-images

*
*

The private email exception does not apply to  apply to a class of authoring
tools, it only applies if you send a private email to a person or people who
you know can see the image.

So depending on who I send it to, will decide if it is conforming or non
conforming so unless the email client provides the ability for me to add a
text alternative it WILL allow non conforming documents to be published.


regards
Stevef



On 18 July 2010 13:00, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>wrote:

> I think email clients should provide an interface for suggesting,
> supplying, exposing, and highlighting the absence of text alternatives, same
> as other authoring tools.
>
> It have to confess it does seem unlikely to me that popular email clients
> will block the sending of an email because it is missing a human-authored
> text alternative for an image, regardless of what the spec says. Does it
> seem likely to anyone?
>
> If we had a means to flag machine-generated alternatives with an attribute,
> it's possible email clients could generate such alternatives better than
> user agents and insert them if asked to send otherwise non-conforming HTML.
>
> On 18 Jul 2010, at 10:30, Steven Faulkner wrote:
> > If we are basing conformance rules solely on what a particular email
> client or authoring tool is likely support,
>
> Don't you mean "what a whole class of authoring tools is likely to
> support", given Maciej's point was it's *not* just one particular email
> client?
>
> We have three options:
>
>   1. Make only conformance rules that are likely to be implemented by all
> classes of authoring tools.
>
>   2. Make conformance rules that are likely to be implemented by all
> classes of authoring tools, with exceptions for particular classes of
> authoring tools.
>
>   3. Ignore likelihood of implementation by authoring tools.
>
> If we followed (3), would we not be ignoring this charter requirement:
> "Availability of multiple, independent, interoperable implementations of
> each deliverable with conformance criteria;, as demonstrated by an
> implementation report (summarizing implementation status against the
> relevant test suite) for *each testable class of product*" (emphasis mine)?
>
> This could block the progress of HTML5 to a standard, unless we dropped
> this requirement: "Authoring tools and markup generators must generate
> conforming documents."
>
> http://dev.w3.org/html5/spec/Overview.html#conformance-requirements
>
> It seems to me this would be a logical consequence of Laura's and Al
> Gilman's argument that whether tools generate conforming documents is a
> "business-policy or personal" issue:
>
>
> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100707#HTML5_Should_Not_Facilitate_the_Creation_of_Inaccessible_Content
>
> http://lists.w3.org/Archives/Public/public-html/2008Apr/0326.html
>
> The reason for favouring (2) over (1), as I understand it, is that it
> requires all authoring tools to create interoperable documents conforming in
> other respects, while still requiring as many tools as possible to follow a
> conformance rule judged important for users.
>
> Would you prefer (1) or (3) as a general approach, and if so, why?
>
> > then there are a lot of other exceptions we should make for email clients
> and authoring tools.
>
> This seems entirely plausible.
>
> I'd recommend raising any conformance changes you clearly identify as
> necessary for email clients as a class as bugs.
>
> However, simply pasting conformance checker output without any assessment
> of why the errors exist, whether HTML5 includes conforming features to match
> the error, and what the cost of switching to those features would be, does
> not demonstrate that the need exists in reality.
>
> Precisely what conformance exceptions do you believe are required by the
> conformance checker output you pasted, and why?
>
> Leaving aside "alt" missing on "img", would not the following code
> alterations address the conformance errors raised *without* most users
> noticing any difference?
>
>  1. Add a "title" element with the subject of the email.
>
>  2. Replace custom attributes like "idlink", "jid", "email", and "alt" (on
> "span") with data-* attributes (or microdata or RDFa).
>
>  3. Omit units on "width" and "height" attributes on "img".
>
>  4. Replace "table", "cellpadding", and "font" with equivalent CSS.
>
>  5. Replace "u" with "button".
>
> --
> 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