# [03:07] <Philip`> annevk: I don't know if I've seen "interoperability" defined anywhere, so I'll make something up and say that interoperability is when authors can write pages that work in all UAs and developers can write UAs that work on all pages

# [03:08] <Philip`> Then the linked-image case is interoperable regardless of how UAs handle <a><img alt=""></a>, because authors can write <a><img alt="Button label"></a> (which will work in all UAs) and developers can auto-generate some link text for <a><img alt=""></a> (which will work on all pages)

# [05:32] <Hixie> http://www.w3.org/2002/09/wbs/40318/dcp/ (as yet unannounced, i think, so don't vote on it yet) is going to be interesting. i wonder why that particular e-mail was chosen as a summary, for instance. and what weird effects there will be in casting the question in such a binary way.

# [11:07] <Hixie> so <p>Hello <img src=world.png alt="World"> how are <img important src=you.png alt="Word">?</p> would render as something like:

# [11:08] <Philip`> hsivonen: The alternative (i.e. <img src=...>) means the UA will have to apply heuristics, so it might ignore all the images or read all their filenames, or might ignore all spacer.gifs since they look decorative, which seems like a worse user experience than just telling the user that there's an image (as would happen with alt="Image")

# [11:09] <Philip`> hsivonen: Users you can't see images would still find the image report tool useful to make sure they've added alt attributes to all their images (and if they've missed some then they could ask someone for suitable text)

# [11:14] <jgraham_> I thought noalt was supposed to indicate a "critical content" image for which no alt text was available?

# [11:15] <Hixie> yes but it was not defined to allow alt="" to be specified with it

# [11:15] <Philip`> hsivonen: Any half-decent content-based heuristics ought to ignore <img src=spacer.gif>, which is bad in this case since it unexpectedly hides some of the image report's images from the user (when they might often want to know about the image so they can copy-and-paste the URI or something) - as the content producer you know more about whether the image is ignorable than the UA can know, and you have to use the alt attribute to communicate that knowled

# [11:20] <Hixie> jgraham_: not necessarily -- it would be annoying as all hell to have "image" read out a billion times

# [11:20] <Philip`> zcorpan: The UA shouldn't ignore the whole link, but I don't see why it couldn't ignore the spacer.gif and treat that pattern the same as <a href></a> and convert it to text as "Empty link"

# [11:20] <jgraham_> Hixie: It basically seems like missing alt would map to important

# [11:20] <Hixie> ...and (continuing my earlier thought) you therefore end up making the default the same as including important="", and the attribute becomes mostly useless, unless we consider saying the kind of image to be a significant win

# [11:25] <Philip`> Users have a more direct incentive to act competently than authors do :-)

# [11:25] <jgraham_> Basically I think that assuming images for which no information is available are decorative is worse information loss than assuming that they are important and risking the possibility that they are not

# [11:25] <Hixie> jgraham_: you could also imagine a UA/AT saying "this page contains 45 unlabeled images." at the start of the read.

# [11:27] <zcorpan> i think that noalt/importantimage/etc would be used incorrectly so much that the user experience will be the same or better if such attributes are ignored

# [11:27] <zcorpan> frankly i think that alt is used incorrectly so much that UAs are better off doing image analysis to decide whether the image should be ignored or not

# [11:28] <jgraham_> It would be good if tool authors could be convinced that accessibility is an important problem that needs to be solved by human-led analysis and so encouraged to provide tools for step-through analysis of the document's accessibility

# [11:29] <jgraham_> If I were an accessibility expert I would spend my time doing that rather than trying to make one accessibility issue get proxied by a syntax requirement that can be caught by a validity check

# [11:30] <jgraham_> (especially given how poor the proxy turns out to be)

# [11:30] <Hixie> the accessibility people doing real work aren't visible in the standards process

# [11:51] <hsivonen> I wonder where the 'acrimonious tone' came from...

# [11:55] <Philip`> (£30 for a new AC adapter? It's just a dumb lump of plastic and metal :-( )

# [12:02] <Lachy> my understanding of important="" was that it would indicate that the image is important content and that the user should attempt to find out more about it through additional heuristics or image analysis, if the alt wasn't sufficient. But then I'm not sure how it's any different from <figure><img src="..."><legend>...</legend></figure>

# [12:58] <Lachy> maybe we should have some way to indicate whether the progress bar is relatively static or dynamic, where a dynamic one is expected to update relatively quickly, and a static may stay the same for a while.

# [12:59] <Lachy> and if there are non-animated progress bars available, they would be used for the static progress bars.

# [13:01] <hsivonen> isn't a non-dynamic progress bar close enough to gauge for all practical purposes?

# [16:53] <Lachy> what we really need for the alt discussion to get somewhere is a study that looks at the reasons why people use alt="" or alt="bogus, validator friendly content" or whatever. The difficulty is in figuring out how to perform such a study

# [16:54] <Lachy> maybe a carefully crafted survey, asking web developers a bunch of questions about the issue would work

# [16:55] <hsivonen> Lachy: no, this is the kind of stuff where you have go look for revealed preferences from actual actions, because if you ask, people lie

# [20:33] <othermaciej> Lachy: Robert Burns saying that alt is not supposed to be used for photos, and others citing his arguments

# [20:33] <othermaciej> am I totally lacking in reading comprehension skills because that seems like the opposite of what AI54 says

# [20:34] <rammic> Can anyone answer a stupid spec question for me? (4.7.5.1. Changes to the networking model) would seem to imply that if a cached application cannot be reached due to network error (downtime?), then the browser should load the cache version- right?