W3C home > Mailing lists > Public > public-html@w3.org > July 2010

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

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Sun, 18 Jul 2010 14:45:40 +0100
Message-ID: <AANLkTim9soCBvkcMLSaqbDSxd7loXEAkt_SQkNAX0Y4b@mail.gmail.com>
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Laura Carlson <laura.lee.carlson@gmail.com>, HTMLWG WG <public-html@w3.org>
A sanity check,

. 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."*


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.


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 -
Received on Sunday, 18 July 2010 13:46:32 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:21 UTC