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

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.
</video>

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:
http://www.w3.org/TR/WCAG10-HTML-TECHS/#animated-images

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:33:51 UTC