/irc-logs / freenode / #whatwg / 2007-12-24 / end

Options:

# Session Start: Mon Dec 24 00:00:00 2007
# Session Ident: #whatwg
# [00:01] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
# [00:01] * Joins: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no)
# [00:06] * Quits: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
# [00:06] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
# [00:08] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
# [00:10] <othermaciej_> csarven: who declared me court jester? that's kinda cool :-)
# [00:11] <gsnedders> othermaciej_: http://blog.fawny.org/2007/12/23/janefonda/
# [00:11] <gsnedders> othermaciej_: not a good context :P
# [00:12] <othermaciej_> dictators don't have jesters
# [00:15] * othermaciej_ is now known as othermaciej
# [00:15] <othermaciej> wow, I'm part of the politburo
# [00:17] <takkaria> oh, a bad metphor to complement the bad analogy :P
# [00:17] <othermaciej> that was a pretty childish post
# [00:18] <othermaciej> "add longdesc... for the children! the poor disabled children!"
# [00:18] <takkaria> or they'll have to hack the system
# [00:20] <othermaciej> Joe seems to think accessibility is too important to apply normal standards of evidence for what features are truly effective
# [00:20] <othermaciej> I think it's too important *not* to
# [00:20] <Lachy_> I didn't get the analogy Joe was trying to make using the story about the airline passenger in a wheelchair
# [00:21] <othermaciej> he's trying to say that it's the working group's moral duty to do all required research to justify accessibility features
# [00:21] * Joins: webben (n=benh@82.152.16.177)
# [00:21] <othermaciej> (perhaps unaware of how much detailed research has been done)
# [00:21] <Lachy_> of course we do
# [00:22] <othermaciej> (and perhaps assuming any research that doesn't justify every single one of HTML4.01's features that are "for accessibility" is prima facie invalid because the experts don't agree)
# [00:23] <Lachy_> we need research to find out what accessibility features actually work and are benefitial to add or retain, not just automatically accept features because they are for accessibility, especially if those features don't actually work in practice
# [00:27] <gsnedders> JAWS implements @longdesc, does it not?
# [00:28] <webben> gsnedders: Both JAWS and Window-Eyes implement longdesc.
# [00:28] <webben> gsnedders: As do add-ons for Firefox and IE.
# [00:28] <gsnedders> webben: the latter is less important for accessibility alone, though, really
# [00:29] <webben> gsnedders: I strongly disagree. If you're colorblind, you might well not use a screen reader but still need a longdesc.
# [00:29] <webben> ditto with screen magnifier users
# [00:29] <gsnedders> that's true
# [00:30] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
# [00:30] <webben> Now I know that HAL doesn't support longdesc and neither does VoiceOver (there's no interface in WebKit; I lost my code which added one and haven't had time to recode it for submission, unfortunately).
# [00:30] <webben> I don't know about the current situation with NVDA and Orca.
# [00:31] <othermaciej> the main problems people have documented with longdesc are that the vast majority of longdesc attributes out there are wrong in various ways
# [00:32] <othermaciej> so following longdesc whenever possible would be actively harmful to the user
# [00:32] <othermaciej> some evidence was also presented that many blind users are unaware longdesc even exists
# [00:33] <webben> Actually, I think a lot of that documentation shows longdesc being misinterpreted as a string value rather than a URI.
# [00:33] <othermaciej> taken together that makes the feature seem somewhat unsuccessful in achieving its intended purpose
# [00:33] <webben> Which means it can be used for error correction of alternative text where necessary.
# [00:33] <othermaciej> I do not think that's the case
# [00:34] <othermaciej> what Hixie found is that many longdescs are links to the image itself, links to the site's top-level page, 404s, irrelevant spam links, stuff like that
# [00:34] <webben> The "blind users" being "unaware" is entirely down to the UI and documentation of assistive tech. (And in fact it's quite clearly documented.) Never mind we're talking about tiny sample sizes of people and a tiny sample of sites.
# [00:35] <webben> othermaciej: A UA that presented a 404 as a longdesc would be a bit silly.
# [00:35] <gavin_> presumably hixie search through his large web archive
# [00:35] <webben> I don't think there's any element or attribute not misused by spammers.
# [00:35] <gavin_> I wonder whether the people arguing for its inclusion care about "the web"
# [00:35] <gavin_> rather than "the web they frequently use"
# [00:36] <webben> I also pointed Hixie to various examples of longdesc used correctly.
# [00:36] <webben> (real examples from government websites for example)
# [00:37] <webben> I think arguing from what AT currently does is highly problematic, given how UAs are trying to hack around broken web content, itself highly determined by flaws in normal UAs.
# [00:37] <webben> *given how ATs
# [00:37] <webben> it's not a technical argument really.
# [00:38] <webben> and in any case Window-Eyes and JAWS do in fact support it.
# [00:39] <othermaciej> webben: well, you don't know it's gonna be a 404 until the user requests to follow it
# [00:39] <webben> othermaciej: It's a longdesc not an anchor or form control. It should be safe for a HEAD request at least.
# [00:40] * Joins: jacobolus (n=jacobolu@pool-72-87-174-165.plspca.dsl-w.verizon.net)
# [00:40] <othermaciej> webben: I suppose you could pre-emptively load all longdesc contents to decide whether to even show the UI to the user, however, that's not what we do with normal hyperlinks
# [00:40] <othermaciej> HEAD requests are not reliable
# [00:40] * weinig is now known as weinig|coffee
# [00:40] <othermaciej> many servers out there give mismatched HEAD results
# [00:41] <takkaria> from the research I did, I found one longdesc being used right in Philip's directory
# [00:41] <webben> othermaciej: Well there's an argument for doing that for normal hyperlinks (preloading) ... particularly ones where alt is missing (image links). The main problem is the misuse of GET requests for destructive actions, although the RoR fiasco with web accelerator may have reduced that abuse. But I very much doubt the same problem exists at any significant scale with longdesc URIs.
# [00:42] <takkaria> out of 62 pages that used longdesc
# [00:42] <webben> takkaria: Yeah, I found more examples than "1".
# [00:42] <webben> (not in Philip's directory, though)
# [00:42] <takkaria> fair enough. if you cite government websites, though, then that's hardly regular usage
# [00:44] <othermaciej> webben: most longdesc attributes do not point to longdesc-specific content, so I don't know if it would be materially different (other than the fact that longdesc in general is so rare)
# [00:45] <Lachy_> Most of the good examples of long descriptions include a regular link, making longdesc redundant
# [00:46] <Lachy_> and the information often includes information that would be useful for more than just those with assistive technology
# [00:47] <webben> Lachy_: There's no reason why longdesc shouldn't be in primary UI.
# [00:47] <Lachy_> the best solution I've seen for the longdesc issue is rel="longdesc"
# [00:47] <webben> Lachy_: That's not very helpful since it can't be programmatically associated with the image.
# [00:47] <Lachy_> it can be when used within a <figure>
# [00:48] <webben> what about when it's not in a figure?
# [00:48] <webben> and what about when your photoshop-mock maker complains about the visible longdesc link?
# [00:49] <webben> visible associations are ideal, but they are problematic in the real world.
# [00:49] <webben> (witness the microformat's movements endless trouble with "visible" yet "hidden" data)
# [00:49] <Lachy_> hidden metadata is more problematic in the real world, and londesc="" simply doesn't work in practice
# [00:49] <othermaciej> the link anchor can be around the image
# [00:49] <webben> It /works/ fine. Saying it doesn't work is like saying alt doesn't work because some people write garbage alt text.
# [00:50] <webben> othermaciej: Not if the image is a link already.
# [00:50] <othermaciej> if it is a link already, then likely a separate longdesc link is unnecessary
# [00:51] <webben> othermaciej: For example. An image of painting of Lady of Shalott linking to the poem. A long description for the painting.
# [00:51] <Lachy_> since authors can always include a <figure> around the image to explicitly associate the <a rel="longdesc" ...>, the case where there is no figure could be considered an error. But that doesn't prevent any heurisitics from making a reasonable guess about which image it's associated with
# [00:51] * Quits: gsnedders (n=gsnedder@host86-138-198-209.range86-138.btcentralplus.com) ("404: Not Found")
# [00:51] <othermaciej> I dunno, I don't really have a horse in the longdesc race
# [00:52] <webben> Lachy_: I think you're wildly underestimating how difficult authors make it to write effective heurestics for that sort of case.
# [00:52] <othermaciej> however, it seems to be the case that very few (less than 1 in 100,000) pages use it, and of those, at best 1 in 1000 use it correctly (that's just eliminate longdescs that simple testing can show you are wrong)
# [00:52] <othermaciej> those are pretty poor odds
# [00:52] <webben> I know AT have had enormous trouble associating fields with labels; I know from experience it's difficult even to conclusively associate permalinks with blog articles.
# [00:52] <Lachy_> webben, there's still the issue that longdesc doesn't work in practice. Authors rarely use properly, and when they do, they most often include a redundant link anyway
# [00:53] <webben> Lachy_: "work in practice" and "is widely used" are completely different things.
# [00:53] <webben> Especially when even accessibility resources have long continued under an apprehension that longdesc isn't supported.
# [00:53] <othermaciej> it's not just rarely used - the rare times it is used, it is usually used wrong
# [00:54] <othermaciej> (at least that's what the stats I have seen seem to show)
# [00:54] <webben> Even that isn't the same thing as "not work in practice".
# [00:54] <Lachy_> given that it's supported with extremely bad UI, treating it as if it's not supported makes little difference
# [00:54] <othermaciej> I guess it depends on how you define work
# [00:54] <webben> e.g. if responsible authors assume it doesn't work, then you'd /expect/ a higher proportion of misuse by spammers
# [00:54] <othermaciej> I would assume the goal of the feature is to convey useful information to the blind and visually impaired
# [00:55] <othermaciej> so far it does not seem to have become an effective way to do that
# [00:55] <webben> othermaciej: That's not exactly the stated rationale in the HTML4 spec.
# [00:56] <webben> although it's certainly a goal.
# [00:56] <othermaciej> this would lead me to at least wonder if other ways of associating a long description might be better
# [00:56] <webben> othermaciej: It's perfectly effective if you let people know that you're using longdesc and they have supporting AT or an add-on.
# [00:57] <webben> Although again I'd tend to say that OBJECT's nesting model is a cleaner solution.
# [00:57] <othermaciej> it's true, HTML 4.01 says "This attribute specifies a link to a long description of the image", but I think it has to be assumed it's not intended for general audiences because then a normal link would be better
# [00:58] <webben> othermaciej: Yeah but it's emphatically not just targeted at disabled users.
# [00:58] <webben> note the rationale given for ALT: http://www.w3.org/TR/html4/struct/objects.html#adef-alt
# [01:01] <webben> In an ideal world, it would always be good to give authors the opportunity to express accessibility information/metadata visibly. In the real world, publishers are never going to always choose to do so. Therefore there will always be a set of publishers willing to express accessibility information/metadata "invisibly" (to some degree) and not visibly.
# [01:03] <takkaria> that set seems to be very small today, though
# [01:03] <webben> So while I think the "hidden metadata is evil" argument is a powerful argument for allowing ways to explicitly markup visible content as being a genuine equivalent for some other bit of content, I don't think it's a real-world argument for preventing authors providing "invisible" equivalents/metadata.
# [01:04] <webben> takkaria: On the contrary, it's vast. ALT is one of the more successful accessibility features. Microformats have been surprisingly successful, given that while they preach visible metadata they practice a lot of invisible metadata.
# [01:04] <webben> (a lot of key data is buried in TITLE attributes)
# [01:05] <webben> I can't imagine a solution where to provide text for a image button you would have needed to make it visible would have been half as successful.
# [01:05] <webben> It certainly doesn't parallel the model adopted for desktop UIs.
# [01:05] <takkaria> true, but given that many people are willing to use alt text, the fact that most of those same people aren't willing to use longdesc, means that the number of people who actually want to provide longdesc must be fairly small
# [01:06] <webben> takkaria: Again clearly false, given alt is /heavily/ evangelized, and longdesc, where mentioned at all by evangelists, has generally being accompanied by caveats about it not being supported.
# [01:06] <Dashiva> alt is just text. longdesc requires a whole webpage.
# [01:07] <webben> Dashiva: Yes. Which is the advantage of the OBJECT model for equivalent content.
# [01:08] <Dashiva> Doesn't that just reduce to using <object> for images?
# [01:08] <webben> Dashiva: Although OTOH it provides reuse potential in practice.
# [01:08] <webben> Dashiva: It's generally said that OBJECT is too broken now.
# [01:08] <webben> and we can't change the content model for IMG, and browsers implement all similar words as though they were images
# [01:08] <Dashiva> I seem to recall IE8 including image-object fixes for their acid2 run
# [01:08] <webben> which is where we get proposals for things like PICTURE
# [01:09] <webben> but PICTURE is supported by nothing, whereas AT already supports longdesc
# [01:09] <webben> *some AT
# [01:09] <webben> *as though they were the IMG element, I should say.
# [01:10] <webben> Dashiva: Yeah, part of the problem here is AT needs to have (if anything) more backwards compat than anything else, since the upgrade time for AT is much longer than the upgrade time for ordinary browsers.
# [01:11] <Dashiva> Well, that's not a given
# [01:11] <webben> Dashiva: It's a reasonable assumption. To assume anything else is to gamble on Orca and NVDA being huge successes.
# [01:11] <webben> (basically)
# [01:12] <Dashiva> Or gamble on AT upgrading being non-broken
# [01:12] <webben> It's like assuming from the start that Firebird was going to win the browser wars ... actually worse, since AT is a much more difficult industry to crack
# [01:13] <webben> Dashiva: A lot of "AT" brokenness is a result of: poor accessibility frameworks (MSAA was pretty useless by most accounts), broken browsers (forcing AT to do the browser's job), and having to cope with real-world broken web content.
# [01:13] <Dashiva> That's not part of the horrible upgrade cycle, though
# [01:13] <webben> and equally important real-world avant-garde web content.
# [01:14] * Lachy_ is now known as Lachy
# [01:14] <Dashiva> Every time AT comes up in a discussion, we're reminded that <large number> of users still use <version current-4>
# [01:14] <webben> Dashiva: given the target is moving all the time (new browser bugs cascading to AT, new forms of broken web content, etc.), it is in a way.
# [01:14] <webben> Dashiva: Yes.
# [01:14] <webben> Dashiva: That's more to do with expense though.
# [01:15] <Dashiva> And that's a problem
# [01:15] <webben> And way outside the ability of the HTML WG/web community generally to do much about.
# [01:15] <Dashiva> It's within the ability of AT companies, though
# [01:15] <webben> (Well, other than inventing new accessible web-based apps which kill MS Office etc.)
# [01:15] <webben> Dashiva: It's not necessarily within the ability of FS and GW-Micro to make their software cheaper without going out of business.
# [01:16] <webben> (Not that I have any special insight into their finances.)
# [01:16] <Dashiva> As a Opera guy I'm all for accessibility, but I do get somewhat frustrated when we're asked to both run accord for AT software being buggy -and- for refusing to allow their users to upgrade
# [01:17] <webben> Dashiva: Well, they do tend to make the intra-version upgrades free.
# [01:17] <webben> Dashiva: And they are (I think) making some efforts to make the upgrade path less expensive.
# [01:18] <webben> GW-Micro introduced some sort of monthly payment scheme which included upgrades IIRC.
# [01:19] <webben> Dashiva: No disagreement that it makes it difficult for the browser and webdev community ... but we are really only a part of what they have to deal with.
# [01:20] <Dashiva> Well, we're all here to cooperate and compromise, what are they offering? :)
# [01:20] <webben> Offering for what?
# [01:20] <webben> (Or what for what?)
# [01:21] <Dashiva> In contributions
# [01:21] <webben> what sort of contributions?
# [01:22] <Dashiva> Activity. In the working group
# [01:24] <webben> Dashiva: Well, I'd certainly like to see more involvement (although HTML WG already has three AT vendors). But (to some degree), it's the browser makers' job to make sure they get a language that can be represented in the OS-level accessibility framework (just like with ODF etc.). And in the case of MS and Apple, both on the WG, it's very much their job to improve the framework where necessary.
# [01:25] <webben> And involvement with HTML WG would probably mean less bugfixes.
# [01:26] <webben> These companies aren't the size of Google, MS, Microsoft, Apple, after all. They don't have proficient developers to spare.
# [01:26] <Dashiva> Strictly feaking, bugfixes don't really matter because we still have to take the old versions into considerations :)
# [01:27] <webben> Dashiva: Well, okay, raising the cost of bugfixes and hence the cost of upgrading.
# [01:27] <othermaciej> I have some influence over what Apple does with VoiceOver and its integration with the browser
# [01:27] <othermaciej> but whatever I do, I can't make things work better in JAWS
# [01:28] <othermaciej> apparently very few blind people use macs, although I'm told the experience is pretty good
# [01:28] <webben> othermaciej: It is pretty good! (although WebKit has some areas to improve as we've discussed before).
# [01:28] * webben subscribes to the macvisionaries mailing list, so he hears a lot of user feedback.
# [01:29] <webben> Hopefully Office 2008 will use the accessibility framework, that would be a big boost. Although I'm not that hopeful that it will.
# [01:29] * weinig|coffee is now known as weinig
# [01:31] <webben> othermaciej: I agree you can't do much about JAWS yet (although that will change when WebKit gets an MSAA/IAccessible2 implementation).
# [01:31] <webben> But there are at least two people with experience of JAWS as normal end-users ... and there's MS as a sort of MSAA representative.
# [01:32] <webben> Don't get me wrong; would like to see an FS rep too!
# [01:32] <webben> Isn't Aaron Leventhal on the WG now?
# [01:33] <webben> Yeah he is (http://www.w3.org/2000/09/dbwg/details?group=40318&public=1) ... he's regularly bug-fixing Moz. for JAWS.
# [01:39] <weinig> does any one know if there is a test suite for the Selectors API yet?
# [01:40] * weinig realizes this is not a whatwg spec and feels silly
# [01:44] * Quits: roc (n=roc@222-154-25-108.jetstream.xtra.co.nz)
# [01:48] * Quits: tndH_ (i=Rob@adsl-87-102-37-105.karoo.KCOM.COM) ("ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508]")
# [01:50] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
# [01:52] <dglazkov> they shoot misanthropes, don't they?
# [01:55] <Dashiva> They do whatever they is defined to be does
# [01:56] <webben> misanthrope shooters definitely do ;)
# [01:57] <dglazkov> Dashiva, don't forget the definition of "is" :)
# [01:58] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
# [02:21] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
# [02:41] <othermaciej> webben: we definitely take requests for accessibility fixes in WebKit, of course
# [02:41] * Joins: jacobolus1 (n=jacobolu@pool-72-87-174-239.plspca.dsl-w.verizon.net)
# [02:41] <othermaciej> weinig: you could ask on #webapi on this server, or ask Lachy or anne, but I don't think there is an official test suite
# [02:42] * weinig nods
# [02:42] <othermaciej> weinig: however, that spec is going into Last Call, I would suggest you should review and get others (Catfish_Man, maybe dethbakin and mitz) to try to review too
# [02:42] <weinig> othermaciej: I was planning on it
# [02:42] <webben> othermaciej: Yeah I know (I've logged some). I need to find time to do some hacking myself for it too. :)
# [02:43] <othermaciej> webben: that is welcome as well
# [02:43] <othermaciej> I need to schedule a meeting with the VoiceOver people to talk about ARIA
# [02:44] <othermaciej> lemme know if you have other things that might be worth discussing with or mentioning to them
# [02:44] <othermaciej> I think a lot of HTML5 elements will help with accessibility
# [02:44] <othermaciej> proper use of <section> / <article> could allow for better navigation
# [02:44] <othermaciej> I dunno how focused they are on accessibility in the browser though, relative to native apps
# [02:46] <webben> othermaciej: From a webkit perspective, I'd say making navigation from bit to bit around the page more predictable is the most important (but unfortunately probably the trickiest) thing.
# [02:46] <webben> othermaciej: Then there are some showstopper bugs like multiple selects being broken to the extent that they can't be read.
# [02:46] <webben> Table support of some sort would be good.
# [02:47] <webben> Another thing would be the ability to skip links.
# [02:47] <webben> VO users sometimes complain about not being able to get to the meat of pages quick enough.
# [02:47] <othermaciej> I dunno what you mean about the multiple selects
# [02:47] <webben> I think being able to skip groups of links (as you can with JAWS and WE)
# [02:47] <webben> would help with that
# [02:48] <webben> (Obviously HTML5 nav could help in the future too.)
# [02:48] <webben> othermaciej: http://bugs.webkit.org/show_bug.cgi?id=15817
# [02:49] <webben> (for the multiple select bug)
# [02:50] <webben> othermaciej: Skipping links would also be good for non-VO users (keyboard/switch users)
# [02:51] <othermaciej> webben: what defines a "group of links"?
# [02:52] <webben> othermaciej: Good question :) In the case of WE and JAWS, you can set a threshold number of non-link characters between links for something to still count as a group of links (I assume that's to cope with pipe characters used in navigation)
# [02:53] <othermaciej> "you can set a threshold" would probably not be an acceptable answer for Mac OS X human interface
# [02:53] <webben> so say you set 3 as a threshhold ... <a href="...">foo</a> | <a href="...">baz</a> is part of a group but <a href="...">foo</a> and also <a href="...">baz</a> is not.
# [02:53] <othermaciej> but series of links w/ no more than some number of characters in between is sorta reasonable
# [02:53] <webben> othermaciej: Well you could devise some sort of algorithm to do something similar I guess.
# [02:53] <othermaciej> I guess we could have a shortcut for that when tab to links is on
# [02:54] * Quits: jacobolus (n=jacobolu@pool-72-87-174-165.plspca.dsl-w.verizon.net) (Read error: 110 (Connection timed out))
# [02:54] <webben> othermaciej: "tab to links" just switches the keybindings round
# [02:54] <webben> it doesn't actually change functionality
# [02:54] <webben> so I'm not sure why one would restrict the functionality to one keybinding scenario or another
# [02:55] <webben> (especially as that would complicate further a feature I've already had to attempt to explain more than once on macvisionaries)
# [02:55] <othermaciej> I don't think it makes sense to have a "tab skipping group of links" shortcut when not in "tab to links" mode
# [02:56] <othermaciej> (can't remember if full keyboard access still enables tabbing to links by default)
# [02:56] <webben> othermaciej: Why not have an option tab skipping group of links
# [02:56] <webben> when in option tab to links mode
# [02:56] <webben> othermaciej: I don't /think/ it does. I'm pretty sure I have to set that manually.
# [02:56] <othermaciej> well, it would have to be an obscure shortcut
# [02:57] <othermaciej> if you have one to suggest we can consider it
# [02:57] <webben> othermaciej: With JAWS you just press N
# [02:58] <othermaciej> tab, option-tab, shift-tab and shift-option-tab are all taken
# [02:58] <webben> granted you can't use N in the main UI though!
# [02:58] <othermaciej> I don't think we'd add a keyboard shortcut on an unmodified key in the default UI
# [02:58] <webben> yep ... my point is more that obscure is not necessarily better
# [02:59] <webben> othermaciej: I suppose one thing to discuss is whether you could use a VO-prefixed shortcut (ctrl option) in the main UI space
# [02:59] <othermaciej> the real problems are first, having a good shortcut, second figuring out how to make it reasonable discoverable, and third, figuring out what to call the feature
# [02:59] <othermaciej> "skip group of links" is not a very clear name
# [02:59] <othermaciej> since the default setting in the normal UI is that focus navigation skips all links
# [02:59] <webben> othermaciej: It's a lot clearer than what the WE manual calls it!
# [02:59] <webben> "Skip to text" IIRC
# [03:00] <webben> othermaciej: Skip navigation might be better.
# [03:00] <webben> (since that's the basic idea)
# [03:00] <othermaciej> so this is supposed to be a heuristic to skip what are intended to be groups of navigation links?
# [03:00] <othermaciej> to get to the main content faster?
# [03:01] <othermaciej> I think a heuristic for voiceover to skip to main content might be the best solution for this use case
# [03:01] <webben> othermaciej: That's the main purpose (although you can also have subsidiary groups of links scattered through the page)
# [03:01] <webben> e.g. tag links following a blog entry
# [03:02] <webben> (or social media sharing links etc.)
# [03:03] <webben> I'd say getting to the main content is roughly 70% of the need.
# [03:04] <webben> (very roughly)
# [03:04] <webben> Getting to the main content may be even harder to create a reliable algorithm for, however.
# [03:10] * Joins: jacobolus (n=jacobolu@pool-72-87-174-206.plspca.dsl-w.verizon.net)
# [03:12] <webben> othermaciej: Another thing would be fixing the context menu so it can be operated with VO as in other apps.
# [03:12] <webben> one of the reasons for that is so that users can add bookmarklets easily
# [03:13] <webben> (which requires activating the context menu and selecting Add Link
# [03:13] <webben> ... that's another thing that came up on macvisionaries
# [03:13] <webben> (sorry this list is a bit random)
# [03:13] <webben> there's a bug filed for context menu and it has a radar
# [03:13] * Joins: roc (n=roc@222-154-25-108.jetstream.xtra.co.nz)
# [03:15] <webben> othermaciej: oh another big thing: fix read all, so people can sit back, relax and have a webpage read to them :) http://bugs.webkit.org/show_bug.cgi?id=15487
# [03:15] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
# [03:16] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
# [03:22] <webben> othermaciej: This was another bug that came out of discussions on macvisionaries: http://bugs.webkit.org/show_bug.cgi?id=15310
# [03:22] <webben> (allow folks to select ranges of text with the keyboard)
# [03:23] * Quits: jacobolus1 (n=jacobolu@pool-72-87-174-239.plspca.dsl-w.verizon.net) (Read error: 110 (Connection timed out))
# [03:23] <othermaciej> does VoiceOver have a standard mechanism for keyboard selection of non-editable text?
# [03:24] <webben> othermaciej: Not sure. Where else do you find non-editable documents that you'd want to copy?
# [03:24] <othermaciej> Mail
# [03:25] <othermaciej> iChat
# [03:25] <webben> don't those both use WebKit for display too?
# [03:25] <othermaciej> IRC clients
# [03:25] <othermaciej> ironically all these things tend to use WebKit
# [03:25] <othermaciej> but that's an implementation detail
# [03:26] <othermaciej> many alerts also have the error text selectable
# [03:26] <othermaciej> iChat didn't use WebKit before Leopard
# [03:27] * Joins: jacobolus1 (n=jacobolu@pool-72-87-174-87.plspca.dsl-w.verizon.net)
# [03:28] <webben> othermaciej: As far as I can tell, in Tiger, text is selectable in a plain text msg in Mail but not an HTML msg.
# [03:28] * Quits: jacobolus (n=jacobolu@pool-72-87-174-206.plspca.dsl-w.verizon.net) (Read error: 104 (Connection reset by peer))
# [03:29] <othermaciej> webben: really?
# [03:29] <webben> but I may be missing something
# [03:29] <othermaciej> how do you start a selection with the keyboard?
# [03:29] <othermaciej> (or do you just mean that selection modification shortcuts work once you have a mouse selection)
# [03:29] <webben> othermaciej: you get a normal character cursor when you focus on the plain text msg area
# [03:29] <webben> so you can use shift
# [03:29] <webben> shift + arrow keys
# [03:31] <webben> othermaciej: I think you need VO on for that to work though
# [03:32] <othermaciej> ah
# [03:32] <othermaciej> probably, yes
# [03:39] <webben> othermaciej: Thinking about it, groups mode provides some of that skipping functionality already (or it would if VO announced "navigation group" rather than just "group") ... it just doesn't handle the jumping to main content bit.
# [03:44] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
# [03:44] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
# [04:26] * jacobolus1 is now known as jacobolus
# [04:31] * Quits: jacobolus (n=jacobolu@pool-72-87-174-87.plspca.dsl-w.verizon.net)
# [05:39] * Joins: othermaciej_ (n=mjs@67-41-138-19.hlrn.qwest.net)
# [05:44] * Quits: othermaciej (n=mjs@67-41-144-107.hlrn.qwest.net) (Nick collision from services.)
# [05:44] * othermaciej_ is now known as othermaciej
# [05:46] * Quits: csarven (n=nevrasc@207.210.58.93) (Read error: 110 (Connection timed out))
# [05:52] * Quits: jruderman (n=jruderma@ip68-5-176-76.oc.oc.cox.net)
# [05:54] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net) ("durr...")
# [06:00] * Joins: Thezilch (n=fuz007@ip68-111-154-116.sd.sd.cox.net)
# [06:04] * Joins: jruderman (n=jruderma@ip68-5-176-76.oc.oc.cox.net)
# [06:20] * Quits: Thezilch (n=fuz007@ip68-111-154-116.sd.sd.cox.net) (Read error: 104 (Connection reset by peer))
# [06:25] * Joins: Thezilch (n=fuz007@ip68-111-154-116.sd.sd.cox.net)
# [06:34] * Joins: doublec (n=doublec@203-97-173-6.cable.telstraclear.net)
# [06:45] * Quits: othermaciej (n=mjs@67-41-138-19.hlrn.qwest.net)
# [06:50] * Quits: doublec (n=doublec@203-97-173-6.cable.telstraclear.net)
# [06:54] * Joins: othermaciej (n=mjs@67-41-138-19.hlrn.qwest.net)
# [07:26] <MikeSmith> webben - you still around?
# [07:27] * MikeSmith sees that webben mentioned "although HTML WG already has three AT vendors" and wonders which three AT vendors that might be
# [07:28] <othermaciej> I assume Apple is one
# [07:31] <MikeSmith> othermaciej - If that's what he meant, I guess MS would be one also.
# [07:33] * Joins: jacobolus (n=jacobolu@pool-71-119-190-119.lsanca.dsl-w.verizon.net)
# [07:38] <othermaciej> I guess Vista includes a built-in screenreader
# [07:39] <othermaciej> not sure how it compares to JAWS
# [07:39] <othermaciej> Apple ships VoiceOver, not just accessibility APIs
# [07:54] <MikeSmith> I wonder how much direct participation WAI has had from AT implementors
# [07:56] <MikeSmith> As far as I can see, no one from Freedom Scientific has ever participated in WAI
# [07:57] <MikeSmith> would be great to have them in the HTML WG but if they've never bothered to get involved in WAI, I guess we shouldn't hold our breath
# [08:36] * Joins: othermaciej_ (n=mjs@67-41-205-11.hlrn.qwest.net)
# [08:37] * Quits: othermaciej (n=mjs@67-41-138-19.hlrn.qwest.net) (Nick collision from services.)
# [08:37] * othermaciej_ is now known as othermaciej
# [09:04] * Joins: hdh (n=hdh@58.187.107.178)
# [09:15] * weinig is now known as weinig|zZz
# [09:32] * Quits: othermaciej (n=mjs@67-41-205-11.hlrn.qwest.net)
# [09:44] * Joins: othermaciej (n=mjs@67-41-205-11.hlrn.qwest.net)
# [10:13] * Joins: ROBOd (n=robod@89.122.216.38)
# [10:21] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
# [10:37] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
# [11:04] * Joins: annevk (n=annevk@c529c1b12.cable.wanadoo.nl)
# [11:08] * Joins: tndH_ (i=Rob@adsl-87-102-37-105.karoo.KCOM.COM)
# [11:08] * tndH_ is now known as tndH
# [11:22] * Joins: heycam (n=cam@124-168-61-74.dyn.iinet.net.au)
# [11:24] * Quits: annevk (n=annevk@c529c1b12.cable.wanadoo.nl) (Read error: 110 (Connection timed out))
# [11:30] * Joins: othermaciej_ (n=mjs@67-41-139-107.hlrn.qwest.net)
# [11:31] * Quits: othermaciej (n=mjs@67-41-205-11.hlrn.qwest.net) (Nick collision from services.)
# [11:31] * othermaciej_ is now known as othermaciej
# [11:35] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
# [11:51] * Joins: zcorpan (n=zcorpan@90-229-146-10-no117.tbcn.telia.com)
# [12:01] * Quits: othermaciej (n=mjs@67-41-139-107.hlrn.qwest.net)
# [12:41] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
# [12:41] * Joins: maikmerten (n=maikmert@L88cc.l.pppool.de)
# [12:59] * Quits: jacobolus (n=jacobolu@pool-71-119-190-119.lsanca.dsl-w.verizon.net) (Read error: 110 (Connection timed out))
# [13:27] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("Leaving")
# [13:29] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
# [13:39] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
# [14:01] * Joins: jgraham (n=james@cpc1-flee2-0-0-cust327.glfd.cable.ntl.com)
# [14:18] * Quits: maikmerten (n=maikmert@L88cc.l.pppool.de) (Remote closed the connection)
# [15:17] * Quits: zcorpan (n=zcorpan@90-229-146-10-no117.tbcn.telia.com) (Read error: 110 (Connection timed out))
# [15:17] * Joins: dbaron (n=dbaron@pool-72-94-185-124.phlapa.fios.verizon.net)
# [15:21] * Joins: gsnedders (n=gsnedder@host86-138-198-209.range86-138.btcentralplus.com)
# [15:45] <gsnedders> Do any UAs already support @rel= noreferrer?
# [15:50] <krijn> gsnedders: re http://www.russellbeattie.com/blog/i-just-added-twitter-into-my-feed#comment-45594 - wouldn't that just become ]]> in a feed?
# [15:51] <gsnedders> krijn: sure, but any unescaped ampersand or less-than sign after?
# [15:51] <krijn> Unescaped?
# [15:52] <gsnedders> <title type="html"><![CDATA[ my broken tweet ]]> & test</title>
# [15:52] <gsnedders> sorry…
# [15:52] <gsnedders> <title type="html"><![CDATA[ my broken tweet ]]> & test]]></title>
# [15:52] <gsnedders> yeah, the actual second ]]> is fine. But the ampersand is a well-formness error.
# [15:52] <krijn> Same question; wouldn't that just become & test .. ? :)
# [15:53] <gsnedders> no, it's a fatal error in XML
# [15:54] <krijn> <title type="html"><![CDATA[ my broken tweet ]]> & test]]></title>
# [15:54] <krijn> That would just work, right?
# [15:54] <gsnedders> no
# [15:54] <krijn> Ow
# [15:54] <gsnedders> yeah, that'd work
# [15:54] <gsnedders> but it leaves a raw & in the HTML :P
# [15:55] <krijn> Wasn't it there in the first place?
# [15:55] * krijn is too stupid to get this ;)
# [15:55] <gsnedders> everything that SP outputs is fine for embedded in HTML: Atom uses escaped HTML.
# [15:55] <gsnedders> s/for/to be/
# [15:56] <gsnedders> using htmlspecialchars() would've been better than using CDATA sections
# [15:56] <krijn> I never use CDATA sections, so perhaps that's why I don't get it :)
# [15:56] <gsnedders> Don't use them.
# [15:56] <gsnedders> :)
# [15:57] <gsnedders> http://hsivonen.iki.fi/producing-xml/#cdata
# [15:57] <krijn> Yeah, that's why I never use them ;)
# [15:57] * Quits: roc (n=roc@222-154-25-108.jetstream.xtra.co.nz)
# [15:59] <takkaria> argh, this house is so christmass
# [16:05] <Philip`> I saw some shops convert their Halloween displays immediately into Christmas displays - I think we need to invent a new holiday in mid-December to take some of the attention away, since otherwise there's too much build-up to Christmas and one gets fed up by the time it's actually here
# [16:06] <takkaria> heh
# [16:06] <takkaria> I'm up for that
# [16:06] <takkaria> mind you, next year I think there's agreement amongst my siblings to have a non-commercial christmas
# [16:09] <gsnedders> Philip`: Oh, Tesco was selling stuff for Halloween in August
# [16:18] * Joins: billmason (n=billmaso@ip156.unival.com)
# [16:58] <Philip`> "P.S. I might turn this into a blog message because hyperlinks and plain text don't mix well." - surely that's what HTML email is for? :-)
# [16:58] <Philip`> (I don't actually know how common or useful HTML email is, since I get Thunderbird to convert everything to plain text...)
# [17:04] <takkaria> hyperlinks mix fine
# [17:04] <takkaria> just use [1] and [2]
# [17:07] * Joins: csarven (n=nevrasc@207.210.58.93)
# [17:09] <gsnedders> wow. it seems even spam bots are on holiday!
# [17:12] * jgraham finds Ben's citation style in email rather hard to read
# [17:14] <jgraham> Specifically things like "Joe's [previous] table collection for
# [17:14] <jgraham> PDF/UA was my starting point" make me think that [previous] is some sort of editorial addition, which doesn't make any sense because it's not a quote...
# [17:15] * Quits: dbaron (n=dbaron@pool-72-94-185-124.phlapa.fios.verizon.net) (Excess Flood)
# [17:18] * Joins: dbaron (n=dbaron@pool-72-94-185-124.phlapa.fios.verizon.net)
# [17:20] <takkaria> gsnedders: oh, I thought I'd finally sorted out my spam filters...
# [17:23] * Joins: zcorpan (n=zcorpan@90-229-146-10-no117.tbcn.telia.com)
# [18:44] * Joins: staaky (n=nosp@cp707947-b.tilbu1.nb.home.nl)
# [18:49] * Quits: jgraham (n=james@cpc1-flee2-0-0-cust327.glfd.cable.ntl.com) ("This computer has gone to sleep")
# [19:46] <takkaria> nutter alert on public-html
# [20:05] * Joins: parcelbrat (n=parcelbr@c-67-185-108-198.hsd1.wa.comcast.net)
# [20:15] * Joins: annevk (n=annevk@5352CE6F.cable.casema.nl)
# [20:15] * Quits: parcelbrat (n=parcelbr@c-67-185-108-198.hsd1.wa.comcast.net)
# [20:18] * Joins: parcelbrat (n=parcelbr@c-67-185-108-198.hsd1.wa.comcast.net)
# [20:19] * Quits: billmason (n=billmaso@ip156.unival.com) (Read error: 104 (Connection reset by peer))
# [20:21] <kig> Philip`: ever implemented svg's elliptical arc path segments?
# [20:27] * Joins: roc (n=roc@222-154-25-108.jetstream.xtra.co.nz)
# [20:27] <Philip`> kig: Nope
# [20:28] <kig> hm, maybe inkscape has an implementation
# [20:28] <Philip`> kig: Looks like it just needs a bit of geometry calculation :-)
# [20:29] <kig> i like how the elliptical arc implementation notes are as long as all the other implementation notes combined
# [20:29] <Philip`> Do you want to emulate it as a series of straight lines, or as a rotated/scaled arc, or something else?
# [20:30] <kig> can't use (easily) transformed arcs in opera, so bezier curves
# [20:30] * Philip` sees that SVG Tiny 1.2 has removed elliptical arcs
# [20:30] * Quits: parcelbrat (n=parcelbr@c-67-185-108-198.hsd1.wa.comcast.net)
# [20:31] <annevk> kig, if something in Opera is causing problems please tell, maybe it's fixable :)
# [20:32] <Philip`> annevk: I think the issue is with Opera following the spec and applying transformations when drawing paths, rather than applying them while constructing paths
# [20:34] <annevk> hmm
# [20:34] <annevk> I think everyone agreed that following the specification for that case would be good, but I guess if Firefox still doesn't do it we're in trouble
# [20:35] <kig> safari doesn't do it either afaik
# [20:36] <annevk> at some point in the past we checked with Safari and Firefox guys and both agreed to change their impl
# [20:38] <kig> for what it's worth, applying transforms to paths at drawing time is just about useless
# [20:40] <kig> the one use-case is "draw this path several times with different transforms", but path construction cost pales in comparison with stroking, patterns and gradients, so it's not a very efficient optimization either
# [20:40] <annevk> http://bugs.webkit.org/show_bug.cgi?id=13669
# [20:42] <kig> (not to mention that you'd need to sort your scene by path at drawing time, which is a pain)
# [20:43] <annevk> https://bugzilla.mozilla.org/show_bug.cgi?id=380338
# [20:43] <annevk> vlad is somehow convinced we agreed that Firefox / Safari behavior was the way to go
# [20:43] <annevk> afaict no such thing happened
# [20:45] <kig> alright
# [20:46] <annevk> i'm willing to believe the non-spec behavior is more useful, but I'm not sure about getting this fixed in time for Opera 9.5
# [20:52] <kig> oh, btw, there's a small bug in Opera 9.5 canvas, full circle arc strokes have a gap with large line widths. i'll make a testcase, sec
# [20:54] <annevk> it would be good if <canvas> was updated once again...
# [20:54] <annevk> (the spec)
# [20:54] <annevk> addressing all of Philip`'s outstanding comments and such
# [20:57] * Quits: weinig|zZz (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
# [20:57] <kig> http://glimr.rubyforge.org/cake/tests/arcStroke.html
# [21:01] <annevk> thanks
# [21:02] * annevk files a bug
# [21:02] <kig> thanks
# [21:08] <annevk> Philip`, are your tests for transforms aligned with the spec or Firefox and Safari?
# [21:17] <Philip`> annevk: We need an HTML55, to fix HTML5 so that it reflects current practice and fixes all the errors related to things like <canvas> :-)
# [21:19] <Philip`> annevk: They should match the spec - see http://philip.html5.org/tests/canvas/suite/tests/results.html / 2d.path.transformation.*
# [21:19] * Joins: parcelbrat (n=parcelbr@c-67-185-108-198.hsd1.wa.comcast.net)
# [21:35] * Quits: parcelbrat (n=parcelbr@c-67-185-108-198.hsd1.wa.comcast.net)
# [21:37] * Joins: jacobolus (n=jacobolu@pool-71-119-190-119.lsanca.dsl-w.verizon.net)
# [21:44] * Joins: weinig (n=weinig@17.203.15.140)
# [21:47] <kig> hooray, inkscape's arcs-to-beziers code works
# [21:53] <webben> MikeSmith: Microsoft: MSAA (backbone of Windows accessibility) + Windows accessibility features and applications (Narrator, a primitive screen reader). Apple: Apple Accessibility API + VoiceOver. T. V. Raman: Emacspeak.
# [21:54] <annevk> hmm ok, so if we fix our implementation a good reference would be breaking all Philip`'s tests
# [21:55] <webben> MikeSmith: also IBM: various products from the shutdown HPR screen reading software to defunct LSR project and the (currently still vapourware) accessible media player they said they were going to release.
# [21:56] <webben> IBM also make ViaVoice; I'm not sure that's under any active development any more either. MS make a speech recognition product which is AT software.
# [21:58] <Philip`> annevk: I'd be happy to update my tests if people agree the spec should be changed
# [22:05] * Quits: jacobolus (n=jacobolu@pool-71-119-190-119.lsanca.dsl-w.verizon.net) (Connection reset by peer)
# [22:05] * Joins: jacobolus1 (n=jacobolu@pool-71-119-190-119.lsanca.dsl-w.verizon.net)
# [22:06] <Philip`> (I think there's at least several other tests that rely on the spec's transformation behaviour, particularly in relation to patterns, so those would break as well if Opera changes)
# [22:22] * Quits: ROBOd (n=robod@89.122.216.38) (Read error: 110 (Connection timed out))
# [22:53] <Philip`> Is there a way to use prompt() in IE7 without it popping up a warning in the information bar instead?
# [22:55] * Quits: jacobolus1 (n=jacobolu@pool-71-119-190-119.lsanca.dsl-w.verizon.net) (Read error: 110 (Connection timed out))
# [22:57] <Philip`> Hmm, it seems the answer is no
# [22:58] <Philip`> Is there any reason they effectively removed prompt(), rather than changing it to use a non-standard appearance so it won't get confused with an 'official' browser window and used for UI spoofing?
# [23:09] * Quits: dbaron (n=dbaron@pool-72-94-185-124.phlapa.fios.verizon.net) ("8403864 bytes have been tenured, next gc will be global.")
# [23:12] <webben> Well, it's a modal dialog I guess.
# [23:17] <annevk> Philip`, ok, cool, I guess I'll know something in January, just ping me around then
# [23:20] <annevk> from previous iterations going through this issue it seems it's slightly painful to do it differently
# [23:20] <annevk> SVG does it like the <canvas> spec does it now it seems
# [23:23] <gsnedders> PHP is so annoying. There's the function, php_charmask(), in the C sourcecode that I need access to in the userland. Ergh. :\
# [23:39] <gsnedders> The behaviour is bizarre too.
# [23:40] <gsnedders> It takes a character list (like "a..z" representing everything between the two, in terms of ASCII codes), and the error handling…
# [23:40] <gsnedders> "a..b..c" parses to array("a", "b", ".", "c")
# Session Close: Tue Dec 25 00:00:00 2007

The end :)