[whatwg] Spec comments, sections 3.1-4.7

On Thu, Aug 13, 2009 at 9:24 AM, Tab Atkins Jr.<jackalmage at gmail.com> wrote:
> I suspect, though, that there are a lot of places you currently don't
> see a progress bar solely because it's a bit of a pain to do. ?Any
> place where progress is being made and displayed is a potential
> candidate. ?In one of the many intranet applications I write and
> maintain for my company, I'm using <progress> right now to indicate
> how far someone is in providing translations for our program. ?I'm
> waiting for browsers to catch up and actually display the element, but
> in the meantime the fallback content is fine.

I guess I don't understand why <progress> is more useful than just
displaying the fallback content to begin with.  Text like "74% done"
doesn't really need <progress>, does it?  There should be no
accessibility problem with that, at least that I can see.  Likewise,
if your progress indicator is made up of one or more <img>s, then you
should be able to use alt text with no accessibility problems.

The only case I can see where progress bars would be an accessibility
problem is if there's a graphical progress bar that doesn't use <img>.
 For instance, something like this to indicate 63% progress:

<div style="height: 1em; width: 100%; border: 1px solid black;
background: white">
    <div style="height: 1em; width: 63%; background: blue"></div>
</div>

This should give you a nice blue bar on a white background that fills
up 63% of the width, showing the user how much progress has occurred
without forcing the client to download an image.  (Assuming I didn't
mess up my CSS.)  In this case, a user who can't perceive the width or
color for some reason would get no information, and there's no easy
way for the author to provide alternative content.  This is the only
use-case I can think of where <progress> would increase accessibility.
 Are there others?

But the case only occurs when the author is concerned enough with
appearances to go out of their way to make a pretty progress bar.  If
they didn't really mind how it rendered on the client, they'd probably
be okay with just using text to avoid accessibility problems.  I'd
think that the author in this use-case is not likely to be happy using
an unstyle-able <progress> element and getting some kind of unknown
appearance that might clash with their color scheme or such.

Is it even anticipated that authors will be able to control the *size*
of <progress> using CSS width or height properties?  Even if that
worked as expected, it would probably interfere with display of
fallback content, so it would be hard to use in practice (you'd need
to serve the CSS only if the UA supports <progress>).  If you can't
even control the size, you'd really have no idea whether it would
stand a chance of working with your layout.  It might cause content to
overflow unpredictably, it couldn't be used in any context where you
need precise positioning, etc.

Are there use-cases for <progress> that I'm missing?  (E.g., are
textual progress indicators not accessible for some reason?)  And am I
being too pessimistic about how important style is for what use-cases
there are?

> Eh, it's not all that bad. ?I'll be happy when I get XBL2, but until
> then I'm fine with platform-native displays.

You're also apparently okay with just having a textual progress
display, so what advantage does <progress> give you?  Do you feel you
have reason to believe that if UAs implement it, it will look better
than the text, even though it might clash with your color scheme or be
a strange size?

> People hack around it
> any case, by providing js libraries that transform your good markup
> into more easily styleable markup (while maintaining accessibility).

That sounds like a maintainability nightmare.  I'm also not sure how
you're supposed to maintain accessibility.  If you transform
<progress> into a <div> using JS, then screen readers that run
JavaScript won't ever see the <progress>, and all benefit will be
lost.  And I assume screen readers need to run JS by default just as
much as normal browsers.

On Thu, Aug 13, 2009 at 10:20 AM, Smylers<Smylers at stripey.com> wrote:
> Many shopping sites have indicators of how far you are through the
> buying process ("Step 2 of 4"), and online surveys often have progress
> bars indicating the position in the survey.
>
> Typically these are static to the page (as in, making progress and
> seeing the indicator move involves submitting a form and displaying the
> next page in the sequence), but so far as I can see from the spec
> <progress> can be used in these situations; it isn't restricted to use
> on a single page where it is updated dynamically.

Yes, those are good points.  Including those does mean there are quite
a few progress bars on the web.  Still, the approach of HTML 5 is that
new features should have concrete use-cases, rather than adding
semantics for the sake of semantics with no specific purpose.  I don't
see how the use-cases given for <progress> are enough to justify its
existence.

Received on Thursday, 13 August 2009 10:34:47 UTC