W3C home > Mailing lists > Public > public-html@w3.org > June 2007

Re: the market hasn't spoken - it hasn't bothered to listened [was Re: fear of "invisible metadata"]

From: Ben Boyle <benjamins.boyle@gmail.com>
Date: Wed, 27 Jun 2007 20:21:32 +1000
Message-ID: <5f37426b0706270321m22238d04p3310852b53cc9035@mail.gmail.com>
To: "Henri Sivonen" <hsivonen@iki.fi>
Cc: "John Foliot - Stanford Online Accessibility Program" <jfoliot@stanford.edu>, "HTML WG" <public-html@w3.org>, wai-xtech@w3.org, w3c-wai-ig@w3.org

Question. What happens in UAs if authors use <video> for an image:

<video src="mycat.jpg">
Fluffy, still only a few inches tall, is playing with a red ball
of yarn that has to 3 times her size. She has just fallen on her back
and it looks like the ball of yarn is crushing her. But she's really
just having fun.

I'm guessing it will fallback, unless UAs support "jpg" in the video
context ... maybe theyll throw a MEDIA_ERR_DECODE error. I know this
sounds a bit silly, but I am thinking about ways of utilising fallback
with images.

Further, I am considering the best way to use animated images (GIF,
SVG... do PNGs support animation?) It might be handy to have video
controls to allow users to stop/start such animations, which is a WCAG
priority 2 checkpoint:

Can <video> be used with flash? Just curious where people think the lines are.

On 6/27/07, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Jun 26, 2007, at 22:57, John Foliot - Stanford Online
> Accessibility Program wrote:
> > the folly of <b> and <i> (and what exactly does italicizing the
> > text mean?)
> As an aside, I think <b> and <i> aren't folly but pretending that
> changing their names to <em> and <strong> solves something is.
> > and a protracted even hostile discussion surrounding the need to
> > preserve headers and ids for
> > tables (as but 3 examples that spring to mind).
> Yeah, but on the other hand, it isn't helpful to say that "foo is
> vital for accessibility" without saying why and what to write as the
> processing model in the spec in a way that makes sense for the long
> term (in the case of headers='' so that the processing model also
> takes into account scope='' as well as implicit "obvious" default
> association).
> > We've not heard one word of
> > the accessibility friendly features being proposed.
> >
> > Perhaps some concrete examples would be apropos?
> <section>, <header> and the outline algorithm
> These features provide a standard way to generate an outline for an
> HTML document. The outline can be used for jumping directly to an
> interesting part of a long document.
> <article>
> This element enables a "Skip to content" feature in UAs where the
> user can't get a quick overview by glance (e.g. aural UAs and visual
> UAs constrained by a relatively small screen).
> <aside>
> This element lets non-visual UAs indicate to the user that a given
> piece of text is not part of the main flow of thought. (Failure to
> indicate this could potentially be confusing.)
> <footer>
> Provides for skipping over administrative information in e.g. aural
> UAs when the user wants to scan a page as quickly as possible
> omitting such notices.
> <nav>
> Enables "Skip over navigation" and "Skip to navigation" features in
> UAs where the user can't easily navigate spatially (non-visual or no
> pointing device).
> <figure>
> The association of a caption with the element being captioned and the
> suppression of the caption when a text fallback is used is at least
> well-intentioned to support the needs of blind readers. Whether the
> design actually meets these needs is debatable judging from recent
> comments.
> <m>
> Makes it possible for non-visual UAs to indicate that a particular
> run of text was highlighted by e.g. a search engine so that a user
> might want to skip to it. (Again, well-intentioned. Whether it is
> actually workable is debatable.)
> <meter>
> Provides for AT access to the state of a gauge widget while making it
> super-easy to make visual gauges that do the right thing AT-wise.
> <time>
> Hopefully helps the microformat community stop polluting the title=''
> attribute of the <abbr> element in ways that interfere with the aural
> Web browsing user experience.
> <datagrid>
> Provides for AT access to complex grid widgets e.g. in browser-based
> email apps like Gmail.
> <details>
> Provides for AT mapping to the UI idiom that in (for example) the Mac
> native UI is visually represented by the disclosure triangle.
> <datalist>
> Makes it easier for users to fill text fields. Provides for AT
> mapping to the combobox UI idiom.
> <output>
> Makes it possible for AT to flag a piece of content as the changing
> result of a calculation. (I have no idea how useful this is in
> practice of how aural UAs or screen readers deal with script-based
> document mutations in general.)
> <progress>
> Provides for AT access to the state of a progress bar widget while
> making it super-easy to make visual progress bars that do the right
> thing AT-wise.
> Various additions to <input type=''>
> Make it easier to adapt input methods to the kind of data the form
> field asks for. For example, if the field wants a number, a speech
> recognition input method could restrict itself to trying to recognize
> numbers only.
> The repetition model buttons
> Make it possible for AT to indicate that a given button adds or
> removes a repeating part (as opposed to indicating a generic button).
> irrelevant=''
> Makes it easy to flag parts of the DOM irrelevant for the current
> moment in time in the life cycle of a Web app UI view so that AT
> should not try to present those parts to the user.
> >> However, for the custom widget case, ultimately native elements for
> >> all available roles and XBL for custom widgets would be a more
> >> elegant long-term solution. I do realize, though, that the main
> >> advantage of role='' over XBL is that role='' doesn't require the
> >> deployed installed base of browsers to participate as a whole in
> >> order for expert authors to target the browsers that do participate.
> >
> > And this argument (and variants of it) have been coming from the
> > accessibility folk for some time.  Henri, go back and research the
> > archives,
> > and see how often it's been countered with "... The majority will
> > never do
> > it..." type responses.  It is one of the key threads in the Pave the
> > Cowpaths discussion.  Not everyone can be an expert in everything,
> > but for
> > those who do specialize in ensuring accessible content ("expert
> > authors"),
> > the tools must exist.  Too often, what we've heard instead is that
> > there
> > needs to be a large enough use-case, or that there are currently
> > not enough
> > viable examples in the wild, or what-ever.  All of these arguments
> > have
> > essentially negated the role (and importance) of said 'expert
> > authors', and
> > their needs.  Our needs may be edge-case, but they are real none-
> > the-less.
> If you come and say that you want a given edge-case solution in the
> spec just because you know you think you need it, you are likely to
> be unsuccessful. On the other hand, if you present a use case,
> present a clean common case solution and *then* as an extra present
> coverage for edge cases *and* explain why the edge case coverage is
> not just chasing for diminishing returns, you are much more likely to
> be successful even if the edge case stuff is the same in both cases.
> > Of course, but then again, the WG also
> > are hoping that these tools will support other new ideas like
> > <canvas> and
> > <progressbar>.  But as you note later (below), attributes such as
> > @role
> > already have some UA/AT support today, so there is a business case
> > to add
> > this capacity to authoring tools today as well.
> Chances are that when authoring tool vendors assess business cases,
> <progress> will have enough of a business case to go with it even
> without considering accessibility whereas the business case for
> role='' hinges on accessibility considerations only.
> >> I agree that HTML5 will need to have role='' and headers='' as short-
> >> term measures and as overrides for handling corner cases when easier-
> >> to-author methods fail. It is rather pointless to make non-conforming
> >> something that Firefox and JAWS already support.
> >
> > Am I hearing a fundamental shift in attitude?  If yes, then hurray!
> In my personal attitude? Not really.
> > (I am still very wary of @class, and it's misuse in "the wild" today),
> The class idea got dropped weeks ago.
> > In short, we should not need to argue for any accessibility
> > construct that
> > already exists - if there is a better way forward, then fine, but the
> > "removal" of any the existing tools should not ever be debated:
> Existing as in "existing in a spec" is not good enough. For something
> to be considered existing, it needs to be implemented in a way that
> works. The debates are part of the finding of fact on whether
> something exists in this latter sense. It is frustrating for those
> who already know, but it is something we need to go through in order
> to define processing models that are compatible with the existing
> implementations.
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
Received on Wednesday, 27 June 2007 10:21:40 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:22 UTC