| 04:53 | <Lachy> | does anyone know if Alan Flavell's resources from http://ppewww.ph.gla.ac.uk/~flavell/ have been mirrored anywhere since they disappeared? Sadly, they appear to have been deleted from the internet archive as well http://web.archive.org/web/*/http://ppewww.physics.gla.ac.uk/~flavell/ |
| 05:01 | <Lachy> | never mind, found them http://web.archive.org/web/*/ppewww.ph.gla.ac.uk/~flavell/ |
| 05:11 | <Lachy> | hey, this page uses longdesc http://web.archive.org/web/20060903033519/http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html |
| 05:12 | <Lachy> | pointing to http://web.archive.org/web/20000814074740/ppewww.ph.gla.ac.uk/~flavell/alt/round-tuit.txt |
| 05:12 | <Lachy> | though, not even that looks like it's a particularly good use of longdesc |
| 05:39 | <Lachy> | this looks like a useful resource http://html.cita.uiuc.edu/text/ |
| 05:43 | <Lachy> | woot! found an excellent example of using longdesc! http://www.webcredible.co.uk/webcreds/episode8.shtml :-) |
| 09:03 | <Hixie> | Lachy: no! it's not an excellent use! because there's a link on that page to the exact same page!! |
| 09:03 | <Hixie> | which is what i've been saying, if it's useful for longdesc, it should (and would) just be available to everyone in a normal link |
| 09:03 | <Lachy> | Hixie, yeah, I know it does, but it's still a good use of a long description |
| 09:04 | <Lachy> | the other example I included in my email to public-html only uses longdesc |
| 09:04 | <Hixie> | http://issues.apache.org/bugzilla/show_bug.cgi?id=13986 |
| 09:04 | <Lachy> | this one http://www.dizabled.com/comics/stairs/ |
| 09:05 | <Hixie> | cool |
| 09:05 | <Hixie> | if you're sending it to public-html make sure to put it in the wiki too :-) |
| 09:06 | <Lachy> | I knew I should have sent to whatwg! :-) |
| 09:07 | <Lachy> | (but I figured it would be better to lead by example and show others on public-html the kind of evidence and constructive emails to post) |
| 09:07 | <Hixie> | hehe |
| 09:15 | <Lachy> | Hixie, in that other link I provided above <http://html.cita.uiuc.edu/text/>;, it lists a whole heap of image categories. It might be useful if spec included examples of advertising banners and CAPTCHA images |
| 09:16 | <Lachy> | the spec seems to cover all the other relevant categories already |
| 09:19 | <Hixie> | cool |
| 09:19 | <Hixie> | did you mail that anywhere? |
| 09:19 | <Lachy> | no, but I will to whatwg |
| 09:19 | <Hixie> | cool thanks |
| 09:22 | <Hixie> | btw, i don't really ever use proposed replacement texts, because i usually find that to make them fit my style i have to make almost as many changes as just writing it from scratch based on the description of the proposla |
| 09:23 | <Lachy> | I tried to make it fit your style (I even used some parts of the existing text) |
| 09:24 | <Hixie> | yeah, but i suffer from NWH syndrome :-) (not-written-here) |
| 09:24 | <Lachy> | LOL! (me too) :-) |
| 09:25 | <Hixie> | hm, the feedback on progress events was sent to whatwg instead of webapi |
| 09:31 | <Lachy> | glad you noticed. I'm on so many lists, I barely notice which email gets sent to where |
| 09:32 | <Lachy> | though I did notice Dmitry Turin is sending more HTML feedback to www-style :-) |
| 09:43 | <Lachy> | the comments on the blog have turned into little more than ad hominem attacks http://blog.whatwg.org/omit-alt |
| 09:55 | <Lachy> | Hixie, Steve Faulkner mentioned this awesome list of resources about alt text. I know you've probably seen many of them already, but there's a few that I hadn't. http://www.d.umn.edu/itss/support/Training/Online/webdesign/accessibility.html#alt |
| 11:28 | zcorpan | wonders if the alt section should s/empty value/empty or placeholder value/ |
| 12:07 | <Lachy> | zcorpan, what do you mean by placeholder value? something like alt="photo" or "unkown"? |
| 12:14 | <zcorpan> | Lachy: yeah, dummy text |
| 12:19 | <webben_> | Is there any research into how hard it would be to explain to ordinary users "how or why to provide alternate text"? While professionals disagree about what provides the perfect alt text, it does not seem difficult to explain how to provide text that would be an improvement over nothing. |
| 12:21 | <webben_> | It seems to me the main obstacle for a site like Flickr to deal with (and this is actually basically limited to photo sharing sites) is how to handle /bulk/ uploads (the problem Maciej keeps mentioning). |
| 12:21 | <webben_> | My suspicion is that this is basically a technical problem, rather than a human problem, to be solved. |
| 12:22 | <Lachy> | webben_, it's a human problem. You try explaining to the millions of typical users, regardless of if they upload in bulk or individually, that they're expected to provide alternate text. |
| 12:22 | <Lachy> | and also teaching them about how to write good quality text. |
| 12:23 | <webben_> | Lachy: No I mean /bulk/ is a technical problem. Alt text is a human problem, but it doesn't seem a massively difficult one. (It's not more difficult to explain to a million users than a 100 users. Or even to 10 users.) |
| 12:23 | <Lachy> | it takes long enough to teach web developers how to write good alt text (many still get it wrong), let alone someone who just wants to upload some happy snaps of their kids birthday |
| 12:24 | <Lachy> | brb |
| 12:24 | <webben_> | I don't think writing alt text is intrinsically easier for your average webdev. |
| 12:25 | <webben_> | (In fact, in so far as webdev's may tend to have backgrounds in scientific or visual arts disciplines rather than highly verbal ones, it may be /harder/ for your average webdev than many other professionals.) |
| 12:27 | <webben_> | Also, webdevs are more likely to be confused by other groups by having read incorrect information about alt, or by being introduced to it primarily as a tool for SEO. |
| 12:28 | <webben_> | the text "my kid's birthday" is itself halfway usable alt text (it's not /perfect/ alt text, but it's usable) |
| 12:38 | <Lachy> | considering the title would probably be something like "Jack blowing out his candles" (assuming the user even bothered to provide that), I don't see how such alt text would be useful |
| 13:00 | <webben_> | Lachy: Well, first, I don't limit the question of alt text to the alt attribute (I'm also considering things like the alt element). Second, repeated text that uniquely identifies an image is preferable to failing to identify it. Third, such alt text is useful when photos are displayed without their titles (as is common on Flickr, e.g. for the photostream list on the right at http://www.flickr.com/photos/minouzers/1230100121/). |
| 13:02 | <webben_> | (Repeated text is better than none because you can select and manipulate the image from a list of items on the page, distinguishing it from the other images on the same page.) |
| 13:08 | <webben_> | alt="" is best reserved for items that should simply be omitted from the page. |
| 13:09 | <webben_> | (and this will never work for widget or link complete content) |
| 13:09 | <Lachy> | why would a user who couldn't see the image and is thus seeing the alternate text want to "select and manipulate the image from a list of items on the page"? |
| 13:10 | <webben_> | Lachy: Because blind users regularly want to share images with sighted peers. |
| 13:10 | <webben_> | e.g. simple use case: Jack's visually impaired grandma wants an image off Flickr to email to her friends. |
| 13:11 | <Lachy> | yeah, saving an image is one thing. But it's the list of items that I'm not so sure about. |
| 13:11 | <webben_> | Lachy: Oh. Lists of things is a common assistive technology technique (providing an alternative for serial processing of the entire page.) |
| 13:11 | <webben_> | e.g. lists of links, lists of images, lists of headings |
| 13:11 | <webben_> | VoiceOver does a sort of list of "items" |
| 13:12 | <webben_> | but it's the same problem if the page is processed serially |
| 13:12 | <Lachy> | hmm. it's just sounding more and more like the "list of links" argument used for using unique link text |
| 13:12 | <webben_> | you can't necessarily distinguish one photo from another without some alt value |
| 13:13 | <webben_> | Lachy: Forget the list. That will just be part of the reality of how users process the page (whether people think it's "reasonable" or not). It doesn't change the problem. |
| 13:13 | <Lachy> | you can distinguish between them when read in context |
| 13:13 | <webben_> | not in the photostream |
| 13:13 | <webben_> | not if you jump around the page |
| 13:14 | <webben_> | not if the developer isn't massively careful when it comes to distinguishing avatar images (in the comments, for example) from "the" photo |
| 13:15 | <Lachy> | well, I'd like some sort of usability study to demonstrate that. In fact, I asked for that a few weeks ago. http://lists.w3.org/Archives/Public/public-html/2007Aug/0577.html |
| 13:15 | <webben_> | Lachy: that being which in particular? |
| 13:16 | <Lachy> | your hypothesis that repeating text in the alt attribute is better than omitting it or a blank value |
| 13:17 | <webben_> | Ah. Yeah. I'd be interested in such a usability study too. It will be difficult to construct effectively I suspect. |
| 13:17 | <Lachy> | I did ask Joshue O Connor in that email if he could help out, since he offered his services for such things, but never heard back about it |
| 13:17 | <webben_> | for one thing, you'd need to give people some tasks where it might help (like the sharing example I gave above) |
| 13:18 | <webben_> | If I had the testing resources at my disposal, I'd led them. But I don't. :( |
| 13:18 | <webben_> | *lend |
| 13:31 | <zcorpan> | Lachy: could you commit your changes to the status script to google code, please? :) |
| 13:31 | <Lachy> | this one http://status.whatwg.org/annotate-web-apps.js ? |
| 13:32 | <zcorpan> | yeah |
| 13:32 | <zcorpan> | http://html5.googlecode.com/svn/trunk/status/ |
| 13:32 | <Lachy> | I got charlvn to add those changes for me, I'll ask him to do it |
| 13:32 | <zcorpan> | ok |
| 13:36 | <Lachy> | I've messaged him, but he appears to be away. You could check it in yourself if you like, though. The only changes were adding everything from the comment with my name in it, getElementsByClassName() and below |
| 13:41 | <Lachy> | he said he'd do it shortly |
| 17:29 | <zcorpan> | ok |
| 17:30 | <zcorpan> | i've written a front-end interface for the status marker updater thing |
| 17:36 | <Lachy> | zcorpan, where is it and how does it work? |
| 17:43 | <zcorpan> | http://html5.googlecode.com/svn/trunk/status/ |
| 17:43 | <zcorpan> | it adds a form to the TOC |
| 17:43 | <zcorpan> | and lots of radio buttons |
| 17:49 | <Lachy> | I don't see a form when I look at the spec |
| 18:00 | <zcorpan> | indeed, it hasn't been moved to status.whatwg.org yet |
| 18:01 | <Lachy> | yeah, I just realised that |
| 18:01 | <Lachy> | is there an easy way to test it out? |
| 18:02 | <zcorpan> | i'll upload a demo, hold on |
| 18:07 | <zcorpan> | hmm, can't access simon.html5.org by ftp atm :( |
| 18:09 | <Lachy> | where's update-markers.php? I don't see it in SVN or on stats.whatwg.org, but it's referenced in the script |
| 18:09 | <zcorpan> | it doesn't exist yet |
| 18:09 | <zcorpan> | someone needs to write it :) |
| 18:09 | <Lachy> | ok, I'm too impatient :-) |
| 18:10 | <markp> | Lachy: ping |
| 18:10 | <Lachy> | yo |
| 18:10 | <markp> | got a minute to talk about NOALT? |
| 18:10 | <Lachy> | sure |
| 18:10 | <markp> | i was intrigued by paul's proposal |
| 18:10 | <markp> | on the blog thread that is now useless |
| 18:11 | <markp> | you or someone mentioned that NOALT had been considered but rejected for lack of a convincing use case? |
| 18:11 | <Lachy> | indeed, it was one of the more constructive posts :-) |
| 18:11 | <Lachy> | yeah, it's not clear why <img noalt> is better than <img> |
| 18:11 | <markp> | can you point me to some background discussion of that? |
| 18:12 | <markp> | well, <img noalt> is explicit, and <img> is implicit |
| 18:12 | <Dashiva> | noalt is worse, because it introduces ambuigity if both noalt and alt, or neither, are present |
| 18:12 | <Lachy> | I thought someone had given a more thorough reasoning on public-html, but I couldn't find it earlier. I'll see what I can find now |
| 18:13 | <markp> | i don't follow; but the addition of noalt would allow the spec to require either alt or noalt (but not both, and not neither) |
| 18:13 | <markp> | a missing alt would be a mistake, and could be flagged as such |
| 18:13 | <Dashiva> | It's easy to say something is not conforming, but we also have to specify how it works when it doesn't conform |
| 18:14 | <markp> | ok, we'll get there |
| 18:14 | <markp> | just brainstorming the idea atm |
| 18:14 | <markp> | i'm just thinking about the case of mass uploads to flickr, as has been discussed |
| 18:15 | <Lachy> | the end of this post from Hixie mentions it briefly http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-August/012378.html |
| 18:15 | <markp> | no alternate text is available, we know that at time of publication, this would let us explicitly state that |
| 18:15 | <Lachy> | the comparison with nohref is a good reason, since that attribute is totally useless |
| 18:15 | <Philip`> | Requiring an explicit <img noalt> makes the no-alt case harder (rather than like <img> which is easier to write than the with-useful-alt case), which sounds like the wrong way to motivate people to add alt text |
| 18:16 | <Dashiva> | I could've missed an argument, but I still don't have any clear distinction in use between "we know there's no alt" and "there's no alt" |
| 18:16 | <markp> | well, making alt required for the past 10 years hasn't done much to motivate people |
| 18:16 | <markp> | dashiva: think about the difference between http 404 and 410 |
| 18:16 | <markp> | 410 is intentional |
| 18:17 | <Dashiva> | But the use is the same - you have no page to show |
| 18:17 | <Lachy> | noalt doesn't really solve any accessibility issue. Even if it does catch on, the validation-badge hunters are just going to stick alt="" or noalt in there to keep the validator happy |
| 18:17 | <Philip`> | I saw alt on two thirds of the imgs I looked at a while ago, so something has made people use it a lot, though that's independent of whether they're actually adding useful alt text |
| 18:17 | <markp> | you're right, noalt doesn't solve any accessibility issue |
| 18:18 | <markp> | an image that should have alternate text, but doesn't, is inaccessible regardless of the exact markup |
| 18:18 | <Philip`> | (Er, I meant half the imgs, or two thirds of the pages with at least one img) |
| 18:18 | <markp> | but i think noalt is a good alternative solution to making alt optional |
| 18:19 | <markp> | the spec could require either alt or noalt |
| 18:19 | <Lachy> | and I personally don't see any practical difference between a validator always issuing an error for missing alt, or issuing a warning to those who request it. |
| 18:19 | <markp> | and a missing alt attribute would be a sign that you forgot something and need to fix it |
| 18:19 | <markp> | if alt is optional, the validator can't flag that |
| 18:20 | <markp> | and people who genuinely forgot it (and would add it if reminded) might miss it |
| 18:20 | <markp> | that seems like an obvious benefit to me, but i can tell i'm not winning any converts yet |
| 18:20 | <Dashiva> | A missing alt would be a problem regardless |
| 18:21 | <markp> | A missing alt would be an accessibility problem regardless |
| 18:21 | <markp> | there, i fixed it for you |
| 18:21 | <markp> | i dislike how html 4 has conflated validation with accessibility |
| 18:21 | <Lachy> | I would expect good validators and authoring tools to be able to notify users of missing alt attributes, regardless of its requirement in the spec |
| 18:22 | <markp> | it's led to the problem we're now faced with, valid markup which is actively harmful to accessibility (because software is auto-filling harmful alt text) |
| 18:22 | <markp> | lachy: the problem with that is that it will add to the "noise" of the validation output |
| 18:23 | <markp> | like if your publishing platform doesn't escape ampersands in urls and you can't do anything about it |
| 18:23 | <markp> | then you go to validate and you can't find the real problems that you can fix, because there's too much noise |
| 18:23 | <Dashiva> | Just because you can't fix it doesn't make it any less a real problem, though |
| 18:24 | <markp> | sigh |
| 18:24 | <Lachy> | it would depend on the validators UI |
| 18:24 | <markp> | i'm not getting anywhere |
| 18:24 | <zcorpan> | markp: validators can still warn about missing alt, and you can have options in the validator to suppress certain warnings or errors |
| 18:24 | <markp> | yeah, ok |
| 18:25 | <Philip`> | Might validation-badge hunters choose to use the most lenient conformance checker that does the minimum amount of required testing before giving them badges? |
| 18:26 | <Lachy> | this is so annoying since I have conflicting opinions |
| 18:27 | <Philip`> | (in which case there is benefit in having the spec require things, rather than hoping conformance checkers will choose to provide warnings, to raise the minimum quality level of conformant conformance checkers) |
| 18:27 | <Dashiva> | Badge hunters tend to mess it up anyhow, I'd say |
| 18:27 | <zcorpan> | Philip`: badge hunters will just use the w3c validator, because other validators aren't w3c approved... :) |
| 18:27 | <Dashiva> | Even if you make them conform to all machine-checkable criteria, they can still play ball with the rest |
| 18:28 | <Philip`> | Badge hunters post badges on their web sites, which gives the badge-providing validator high visibility and high search-engine-findingness and everything, so it is likely to become the most popular validator, so well-meaning people who want to properly validate their pages to find problems will end up using that one too |
| 18:29 | <zcorpan> | Philip`: require things doesn't necessarily improve the badge hunters' quality of their markup |
| 18:29 | <Philip`> | (Or at least that's why I've only ever used the W3C validator, because I don't hear about any probably-better validators and there aren't loads of badges pointing me at them) |
| 18:30 | <Lachy> | so Henri should issue badges for everything, like different grades depending on the number of errors :-) |
| 18:30 | <Dashiva> | A+++ would validate again |
| 18:30 | <gsnedders> | badges! |
| 18:30 | <zcorpan> | "This page is Invalid! Look for yourself!" |
| 18:31 | <Lachy> | zcorpan, there's already a badge for that :-) |
| 18:31 | <zcorpan> | oh snap |
| 18:31 | <Dashiva> | Oh yeah |
| 18:31 | Dashiva | goes to read that article again |
| 18:31 | <Philip`> | http://www.mikeindustries.com/blog/archive/2004/06/march-to-your-own-standard ? |
| 18:31 | <Lachy> | that's it! I was looking for that |
| 18:32 | <Philip`> | (found via http://blogs.msdn.com/michkap/default.aspx ) |
| 18:33 | <zcorpan> | but where's the badge? |
| 18:33 | <Lachy> | it seems to be gone |
| 18:34 | <Lachy> | http://www.mikeindustries.com/blog/images/validatethis.gif |
| 18:34 | <Philip`> | The blogs.msdn.com page does have the badge, just under the (Tick!) Unicode ENCODED |
| 18:34 | <Lachy> | he used to have it in his sidebar http://web.archive.org/web/20050123150650/http://www.mikeindustries.com/blog/archive/2004/06/march-to-your-own-standard |
| 18:35 | <Dashiva> | He sold out! |
| 18:35 | <Lachy> | his page is still invalid, even without the badge |
| 18:42 | <Lachy> | apparently UAAG actually requires UAs to treat <img> and <img alt=""> differently. http://www.w3.org/TR/UAAG10/guidelines.html#tech-missing-alt |
| 18:48 | <Lachy> | markp, http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-April/010995.html has more reasoning. |
| 18:48 | <Lachy> | and all the other mails about noalt if you're interested http://lists.whatwg.org/mmsearch.cgi/whatwg-whatwg.org?config=whatwg-whatwg.org&restrict=&exclude=&method=and&format=short&sort=score&words=noalt |
| 18:52 | <Lachy> | "In SMIL 1.0 [SMIL], on the other hand, alt is not required on media objects." -- http://www.w3.org/TR/UAAG10-TECHS/guidelines.html#tech-missing-alt |
| 18:53 | <Lachy> | I wonder if that lack of requirement has harmed the accessibility of SMIL in any way |
| 18:54 | <takkaria> | is SMIL actually used anywhere? |
| 18:54 | <Lachy> | I don't know |
| 19:30 | <webben_> | takkaria: I suspect in most cases where people have thought about using SMIL, they've ended up using Flash. Although SMIL actually has widespread support in some form (e.g. Internet Explorer, RealPlayer. QuickTime), Flash content can be played in-page in Gecko and WebKit. Plus, there are far more people who already know how to author in Flash. (Given the prohibition on using the Flash spec to create new plugins and players, this isn't necessarily |
| 19:31 | <takkaria> | you got cut off at "necessarily" |
| 19:31 | <webben_> | sorry. |
| 19:31 | <webben_> | necessarily ... a great idea, but you can see the market forces driving it |
| 19:32 | <takkaria> | right |
| 19:32 | takkaria | nods |
| 19:33 | <webben_> | There are plenty of experiments with SMIL (e.g. http://www.domsmith.co.uk/computing/bbc-backstage/smil-news/ ), but I suppose broadcasters tend to be more interested in getting a big audience right now than picking the best technology for maximising audience over the long-term. If SMIL has a current home, I suspect it would be for DVD presentation-type things. |
| 19:35 | <webben_> | In theory, there's no big barrier to global SMIL adoption. There's an open source player and plugin, Ambulant, which seems to implement the spec a lot better than the closed-source alternatives. |
| 19:35 | <webben_> | http://sourceforge.net/projects/ambulant/ |
| 19:36 | <webben_> | takkaria: Oh, actually, one actual widespread use for SMIL is DAISY: http://www.daisy.org/z3986/ |
| 19:37 | <webben_> | but you don't see much DAISY content on the web (because the content created in DAISY is usually limited to access by registered people with visual impairments) |
| 19:37 | <webben_> | I think DAISY (or at least some forms of DAISY) use a SMIL wrapper. |
| 19:38 | <webben_> | here's the spec: http://www.daisy.org/z3986/2005/z3986-2005.html |
| 19:38 | <takkaria> | ta |
| 19:38 | <takkaria> | interesting. :) |
| 19:50 | <webben_> | takkaria: hmm also interesting: http://www.kaourantin.net/2007/08/what-just-happened-to-video-on-web_20.html "You can easily write your own SMIL parser in ActionScript though." |
| 20:04 | <takkaria> | well, it's XML, so it's not that surprising |
| 20:06 | <webben_> | guess not |
| 20:06 | <zcorpan> | what is "SMIL parser"? |
| 20:07 | <webben_> | zcorpan: I guess it would turn SMIL into a SWF animation. |
| 20:07 | <webben_> | (that is to say, a SMIL parser wouldn't be much use without rendering) |
| 20:07 | <zcorpan> | so an implementation of SMIL |
| 20:07 | <webben_> | yeah |
| 20:08 | zcorpan | would like to study SMIL implementations sometime |
| 20:08 | <zcorpan> | in particular how they deal with namespaces |
| 20:10 | <webben_> | well the ambulant implementation is supposed to be "namespace-based": http://lists.w3.org/Archives/Public/public-evangelist/2006Aug/0003.html |
| 20:11 | <webben_> | whatever that means |
| 21:03 | <Dashiva> | IE7 doesn't seem to want to update its attribute selector selection |
| 21:06 | Dashiva | hates forcing reflows |
| 21:22 | <Dashiva> | Summary of adapting whatwg/issues for IE7: helper function for textContent, helper function for hasAttribute, force reflow on 'irrelevant' attribute toggling, workaround for missing white-space:pre-wrap support. |
| 21:25 | <zcorpan> | Dashiva: fun :) |
| 21:27 | Philip` | hopes there aren't people with AT that only supports IE6, not IE7 |
| 21:28 | <Dashiva> | Supporting IE6 would probably be easier, since they don't support attribute selector to begin with, so you don't need to reflow to show content :) |
| 21:30 | <Philip`> | Wouldn't it be harder since you'd have to emulate attribute selectors via some other method? :-) |
| 21:31 | <Dashiva> | Not really. It's just [irrelevant]{display:none;} so it could just as easily be replaced by .style.display = 'none'; now that I have hte helper functions in place |
| 21:32 | <Dashiva> | Didn't hixie mention something about the API being public and/or documented and/or otherwise usable? |
| 21:33 | <webben_> | Philip`: Probably (based on reading user mailing lists) a slim majority of AT users have AT that either only supports IE6 or works better with IE6 than IE7. |
| 21:33 | <webben_> | Philip`: In addition, many users downgrade from IE7 they hate it so much. |
| 21:36 | <Philip`> | Dashiva: Do you mean http://www.whatwg.org/issues/API ? |
| 21:37 | <Dashiva> | I probably do |
| 21:38 | <Philip`> | It does seem to be public and documented and usable, and it doesn't even generate ill-formed XML any more |
| 21:41 | <Dashiva> | I don't particularily like the listen stream format, but one makes do I suppose |
| 21:41 | <Dashiva> | There would be even more screaming if it required support for event-source :D |
| 21:43 | <Philip`> | Even more if it used TCPConnection - it would still be perfectly standards-based, but also perfectly useless |
| 21:44 | <Hixie> | there's actually another API below this one |
| 21:44 | <Hixie> | which doesn't use HTTP |
| 21:45 | <Dashiva> | By the way Hixie, there's still no action when you click the vote/remove vote button |
| 21:46 | <Dashiva> | You have to reload for the button text to change |
| 21:46 | <Hixie> | in what browser? |
| 21:46 | <Dashiva> | I'd say all of them based on the code, but I've only tried opera and IE so far |
| 21:47 | <Hixie> | works fine in firefox, opera, and safari for me |
| 21:47 | <Philip`> | It worked when I tried it in Firefox |
| 21:47 | <Dashiva> | Ah right, it's being set after the listen echo... |
| 21:48 | <Dashiva> | I haven't got that one to proxy properly yet |
| 21:49 | <Dashiva> | (Another reason I would prefer a pull option, with XML to avoid string parsing) |
| 21:50 | <Hixie> | yeah i can actually give you another protocol for that |
| 21:50 | <Hixie> | hold on |
| 21:50 | <Dashiva> | No hurry, I'm finished for today :) |
| 21:58 | <mpt_> | zcorpan, "validators can still warn about missing alt, and you can have options in the validator to suppress certain warnings or errors" is like those badly-designed GUIs that have "Are you sure?" alerts with "Do not warn me again" checkboxes |
| 21:58 | <Hixie> | i've start updating API, i'll let you know when it's done |
| 21:59 | <Hixie> | can't do it now |
| 21:59 | <mpt_> | zcorpan, in both cases, the problem is not that some people always want the warnings and some people never want them, but that for *everyone* the warning is useful *sometimes* |
| 22:00 | <mpt_> | And the solution is to prevent the warning from being necessary in the first place. |
| 22:01 | <mpt_> | If I'm a conscientious Web application author, noalt would let me distinguish between images that had no alt text because they were user-supplied, and images that had no alt text because I'd accidentally left it out. |
| 22:02 | <mpt_> | Just omitting alt= doesn't let me do that, it leaves me having to choose between zero validation warnings and too many validation warnings. |
| 22:03 | <zcorpan> | mpt_: the case markp described was actually in specific cases -- "like if your publishing platform doesn't escape ampersands in urls and you can't do anything about it ... then you go to validate and you can't find the real problems that you can fix, because there's too much noise" |
| 22:03 | <mpt_> | I don't understand that analogy, but I agree with the rest of markp's point. |
| 22:05 | <zcorpan> | if a validator complains about something you can't fix, then the straightforward solution to get rid of the noise is to suppress the warning/error in the validator |
| 22:05 | <zcorpan> | imho |
| 22:07 | <mpt_> | zcorpan, absolutely, but it's better to be able to do that for individual images or types of image that you can't provide alt for ahead of time (using noalt) than for every image in the document (using the validator option). |
| 22:08 | <mpt_> | Otherwise you can't test for mistakenly missed alt= on any page where people can upload their own images. |
| 22:08 | <zcorpan> | however i realise that adding alt="" as a way to suppress warnings might be more appealing than changing options in the validator, which is an argument for noalt |
| 22:09 | <zcorpan> | mpt: true |
| 22:14 | <webben_> | I'm not really sure what weight this "validator" stuff holds when most of the web consists of invalid HTML. |
| 22:14 | <webben_> | (and people concerned with accessibility "validation" tend to use dedicated checkers) |
| 22:15 | <zcorpan> | indeed |
| 22:15 | <webben_> | and the sites like Flickr that we appear to be worrying about don't publish valid HTML |
| 22:15 | <webben_> | it seems like a bit of a red herring, i dunno |
| 22:16 | <webben_> | (well, red herring is an exaggeration, perhaps more of a debate about the number of angels on a pinhead ;) ) |
| 22:17 | <mpt> | I don't think the existence of dedicated accessibility checkers should allow the HTML specification to make some things inherently uncheckable |
| 22:17 | <webben_> | mpt: I don't follow. Can you please rephrase? |
| 22:18 | <mpt> | Sure. How do you propose that *the accessibility checker itself* do the checking, if it can't tell the difference between "this image has no alternate text because it's user-supplied" and "this image has no alternate text because we forgot it"? |
| 22:21 | <webben_> | mpt: Oh. I wasn't making an argument against noalt or whatever. I was just saying I think the discussions around alt are probably placing more emphasis on validation and the effects of people validating and creating fake alt text to validate then they actually deserve. |
| 22:22 | <webben_> | Especially as replacing loads of fake alt text with no alt text or noalt does not make for a massively more accessible document. |
| 22:22 | <webben_> | noalt might offer marginal improvements |
| 22:22 | <webben_> | e.g. in Flickr you could distinguish content images from decorative images, maybe. |
| 22:22 | <mpt> | Given the expected lifespan of HTML5, I think the discussions about it are giving remarkably little emphasis to *everything* :-) |
| 22:23 | <webben_> | mpt: I guess I mean, too much weight in comparison to other factors. :) |
| 22:24 | <mpt> | I think the argument about <img src="foo" noalt> being no more accessible than <img src="foo">, *that* is the red herring |
| 22:24 | <mpt> | This isn't about the final document, it's about the authoring process. |
| 22:24 | <zcorpan> | from a UA's point of view, how do you handle an <img> that has neither alt nor noalt? same as alt=""? same as noalt? |
| 22:24 | <webben_> | zcorpan: It depends on context. |
| 22:24 | <mpt> | Same as noalt, I think |
| 22:25 | <zcorpan> | webben_: what, quirks mode/standards mode? :) |
| 22:25 | <mpt> | but again, that's not the issue here |
| 22:25 | <webben_> | zcorpan: e.g. <a href="foo"><img alt=""></a> is very different to bla bla bla<img alt="">bla bla bla. |
| 22:25 | <Philip`> | Use UA-dependent heuristics to guess what would be the most useful replacement text |
| 22:26 | <webben_> | zcorpan: and bla bla bla<img>bla bla bla is different again |
| 22:26 | <Philip`> | (because then it's not our problem :-) ) |
| 22:26 | <Philip`> | (and it's presumably what people do already when alt is missing) |
| 22:26 | <zcorpan> | webben_: right |
| 22:26 | <webben_> | Philip`: Well it would be useful to try and work out if there's a good common algorithm (a la the work that's going on with th/td associations) |
| 22:31 | <webben_> | likewise it would be useful to have ways of associating text elsewhere with the image (figure/legend, the proposed alt element, perhaps an altfor attribute) |
| 22:46 | Philip` | needs to try re-running his web survey thing to get more data (like common values of certain attributes, and maybe content-types of linked scripts/stylesheets/images/etc to see how bad that is, and I can't think of much else yet - suggestions would be appreciated :-) ) |
| 22:46 | <Philip`> | (But I need to remember how to write Java first, so I can use hsivonen's parser) |
| 22:47 | <webben_> | Philip`: maybe create a suggestion page or something for the next iteration? |
| 22:47 | <webben_> | hmm ... maybe that would end up duplicating that wikipage Rob Burns was creating on Research needing to be done. |
| 22:49 | <webben_> | Philip`: Did you collect longdesc data already btw (and does your sample include lots of .gov and .edu sites, which seem more likely to use longdesc)? |
| 22:51 | <Philip`> | webben_: Not specifically - all I have is the general attribute-occurrence information at http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/attr/longdesc |
| 22:52 | <webben_> | oh |
| 22:52 | <webben_> | Philip`: it would be interesting (well to me anyhow) to see a table with img in one column and a longdesc link in the next column |
| 22:53 | <webben_> | I've found plenty of vaguely appropriate longdesc's but it would be nice to try and see more examples. |
| 22:54 | <Philip`> | Out of 8192, I had 31 .gov and 175 .edu |
| 22:54 | <Philip`> | (*numbers of pages) |
| 22:54 | <webben_> | well that's some |
| 22:54 | <Philip`> | (This is a random sample from dmoz.org's list) |
| 22:55 | <webben_> | It might help at some point to do some sort of clumping differentiation based on what sort of site given markup is on. |
| 22:55 | <Philip`> | (It'd be easy to do a sample of e.g. all .gov sites extracted from dmoz.org's list) |
| 22:55 | <webben_> | cool |
| 22:55 | <Philip`> | Comparing the dmoz.org data vs the Alexa top 500 shows some very significant differences |
| 22:56 | <webben_> | I wonder how representative or not dmoz is generally. |
| 22:56 | <Philip`> | (http://canvex.lazyilluminati.com/misc/stats/analyse.cgi/index vs http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/index) |
| 22:57 | <mpt> | When I spent some time reading through dmoz-related discussions a few years ago I got the impression that it was a pile of fiefdoms |
| 22:57 | <Philip`> | (<script> and <form> were the most obvious differences that I noticed) |
| 22:58 | <webben_> | Philip`: Have you considering pushing beyond home pages? |
| 23:00 | <webben_> | e.g. for stuff like longdesc, you wouldn't normally expect to find that on a homepage. |
| 23:07 | <Philip`> | webben_: I've not really thought in any detail how to find a good set of pages to analyse |
| 23:08 | <Philip`> | Some kind of crawler would be good, but I don't know how to make it find interesting pages and to not get stuck in a few deep sites |
| 23:13 | <webben_> | I've often wondered whether it would be possible to use the Internet Archive's database. But I dunno how deep that really goes either. |
| 23:15 | <Philip`> | I think working out which set of pages to examine is a more difficult problem than actually downloading the pages, and I imagine the IA archive doesn't help with the first problem |
| 23:15 | <webben_> | I think these trawlings are more helpful for finding examples of markup in use, then for the statistics (because the sampling is inevitably going to be kinda skewey unless you take samples of very specific things, e.g. how is markup used on Wikipedia or Blogger or something). |
| 23:16 | <webben_> | I guess I was thinking the IA Archive is going to be a different set then DMOZ.org. But actually I have no real idea how IA is collected anyhow. |
| 23:16 | <webben_> | might be through dmoz ;) |
| 23:18 | <webben_> | oh i see, it's like Alexa Top 200, but everything: http://www.archive.org/about/faqs.php |
| 23:18 | <webben_> | I guess even then there might be issues like: have academic collections (which might feature longdesc more, or whatever) asked to be removed from WayBack. |
| 23:19 | <Philip`> | (I think the mean HTML page size is about 30KB (or was it 60KB?) so you can look at tens of thousands in a few hours on a relatively normal internet connection) |
| 23:19 | <webben_> | that's pretty good |
| 23:21 | <Philip`> | It'd be nice if Google web search had a regexp feature like Google code search :-) |
| 23:21 | <webben_> | It certainly would. |
| 23:21 | <webben_> | You could construct some very interesting web services around that. |
| 23:22 | <webben_> | e.g. find microformated content for X |
| 23:23 | <webben_> | or find images with alt="*kitten*" ;) |
| 23:31 | <zcorpan> | hmm, safari doesn't reflow on className change :( |
