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

Hi all,

The stopping/restarting of animations is also included in the section 508 refresh being proposed here in the United States.

> -----Original Message-----
> From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org]On
> Behalf Of Ben Boyle
> Sent: Wednesday, June 27, 2007 3:22 AM
> To: Henri Sivonen
> Cc: John Foliot - Stanford Online Accessibility Program; HTML WG;
> wai-xtech@w3.org; w3c-wai-ig@w3.org
> Subject: 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 15:34:36 UTC