| 00:03 | <webben> | Hixie: Expose the treeitem as a treeitem role and the checkbox as a checkbox role in the accessibility framework, I think. |
| 00:03 | <Hixie> | which means what, assuming you are implementing the accessibility framework? |
| 00:04 | <Hixie> | can i activate a treeitem role? what does it do when activated? |
| 00:04 | <webben> | Hixie: That's not defined by the role. |
| 00:04 | <Hixie> | that's the problem |
| 00:04 | <webben> | Hixie: How? |
| 00:05 | <webben> | The main point of the roles is to map to roles in accessibility frameworks, not to imply a series of behaviours to be implemented by the browser rather than specified by authors. |
| 00:05 | <webben> | (or by specifications like XForms, HTML5, etc.) |
| 00:06 | <Hixie> | to me that seems singularily pointless |
| 00:06 | <Hixie> | but ok |
| 00:06 | <Hixie> | i stil don't know what that means, e.g. from a testing point of view |
| 00:06 | <Hixie> | nor do i know what it means to expose an element as having a role to an accessibility framework |
| 00:07 | <webben> | Hixie: Have you had a look at the Gecko documentation on exposing HTML content to MSAA? |
| 00:07 | <webben> | (and AT-SPI) |
| 00:07 | <Hixie> | what about it? |
| 00:07 | <Hixie> | i understand that there are system-provided APIs |
| 00:07 | <webben> | Hixie: well, that talks about "what it means" (there's an interesting doc also about how to implement an MSAA server) |
| 00:08 | <webben> | http://www.mozilla.org/access/windows/msaa-server |
| 00:08 | <Hixie> | i just don't know how to tell if an application's implementation is conforming |
| 00:08 | <Hixie> | i have JAWS here. work me through a test that shows whether or not a UA implemented a role correctly or not. |
| 00:08 | <webben> | Hixie: I think that's verging into the "telling applications and operating systems how to work" rather than the "how to read HTML" category |
| 00:09 | <webben> | Hixie: Ah now that sort of test wouldn't be so hard. |
| 00:09 | <webben> | If you've got a div made into a WAI-ARIA checkbox, and Firefox fails to expose it as an MSAA checkbox, then that would (likely) be a failure of some sort |
| 00:09 | <webben> | Using JAWS to test wouldn't be a great idea though. |
| 00:09 | <Hixie> | (also, exposing things to accessibility frameworks isn't enough. if something is a tree item, it should act as a tree item whether or not i have an AT. accessibility isn't just for the disabled.) |
| 00:10 | <webben> | Hixie: Yes. But that's not from what I can see the job of WAI-ARIA. |
| 00:10 | <Hixie> | how can i tell if firefox exposes it as an MSAA checkbox? |
| 00:10 | <webben> | Hixie: use MS's accessibility inspecting tools? |
| 00:10 | <Hixie> | the point is that whatever does the job i described above, can automatically do all of the stuff role= can do |
| 00:10 | <webben> | or indeed I think the ICITA extension for Firefox now does that |
| 00:11 | <Hixie> | so the only way to tell if firefox is doing the right thing is to use a debugging tool? it doesn't actually affect users at all? |
| 00:11 | <webben> | Hixie: Not in the case of div widgets. |
| 00:11 | <Hixie> | the div widgets *should also act as tree items* even when, e.g., scripting and css are disabled |
| 00:11 | <webben> | Hixie: No... the point is that using the debugging tool separates what Firefox is doing from what JAWS is doing with MSAA (and other things) |
| 00:12 | <webben> | Hixie: Or fallback. |
| 00:12 | <webben> | Hixie: Which is what you suggesting for HTML5 in current UAs like IE. |
| 00:12 | <webben> | *suggested |
| 00:12 | <Hixie> | ? |
| 00:13 | <webben> | Yesterday you said new HTML5 widgets could be scripted and styled to look the same in IE as in other browsers. |
| 00:13 | <Hixie> | sure, fallback support in many cases has to be secret |
| 00:13 | <webben> | sorry? |
| 00:13 | <Hixie> | we're talking about browsers that implement the new features (be that wairole or whatever) |
| 00:13 | <Hixie> | er |
| 00:13 | <Hixie> | has to be scripted! |
| 00:13 | <Hixie> | my bad |
| 00:14 | <webben> | Hixie: Yes, but if the scripting is changing the DOM so that checkboxes become divs... then the semantics need to be preserved. |
| 00:15 | <Hixie> | if the scripting is changing the DOM so that checkboxes become divs, the scripting has removed the semantics. |
| 00:15 | <webben> | (and that's what authors will continue to do in the short to medium term if indeed they bother with fallbacks at all, given lack of implementations for XBL2) |
| 00:15 | <webben> | Hixie: Not with WAI-ARIA. |
| 00:15 | <Hixie> | if this is about "preserving semantics" they should be preserved for *all* users, not just those that use ATs |
| 00:16 | <webben> | Hixie: What does "preserving semantics" /mean/ for non-AT users of Dojo? |
| 00:16 | <webben> | Hixie: e.g. is this about restyling? |
| 00:16 | <Hixie> | it means that if they have, e.g., a bookmarklet that checks all checkboxes, that should still work |
| 00:17 | <webben> | Hixie: I guess WAI-ARIA faciliates that through XML Events. |
| 00:17 | <Hixie> | eh? |
| 00:18 | <Hixie> | how does XML Events help anything in IE |
| 00:18 | <Hixie> | heck how does WAIROLE help anything in IE |
| 00:19 | <webben> | Hixie: It doesn't. It helps the users who can't use Ajax apps in IE by giving them the option of using Fx instead. |
| 00:20 | <webben> | (Fx being the other major window browser that has screen reader support) |
| 00:20 | <webben> | *Windows |
| 00:20 | <Hixie> | so why not have firefox implement xbl2 instead? |
| 00:20 | <Hixie> | since you're requiring the authors to do something in their markup anyway, and since you're requiring users to switch to another UA anyway, why not just do it right? |
| 00:21 | <Hixie> | wairole seems to be so fundamentally the wrong way to address the problem that I just don't understand how it came to be |
| 00:21 | <webben> | Hixie: That's something for the XBL2 spec writers to take up with AT developers, browser developers, and framework developers, none (?) of whom seem to have shown a vast interest in XBL2. |
| 00:23 | <webben> | Hixie: I suspect, for one thing, it's a lot easier to add WAIROLES to existing codebases using Dojo than to convert Dojo apps to XBL2. |
| 00:23 | <Hixie> | sure, but why isn't it up to the people who designed wairole to design a decent solution? |
| 00:23 | <webben> | but that's only a guess |
| 00:23 | <webben> | Hixie: They're not solving the same problem. |
| 00:24 | <Hixie> | the problem is "people are using html to convey semantics without encoding those semantics in the language", right? |
| 00:24 | <webben> | (Also there's no incentive to use XBL2, because then you couldn't control presentation in IE.) |
| 00:24 | <webben> | Hixie: Not entirely no. |
| 00:24 | <Hixie> | i don't really understand the problem then |
| 00:24 | <webben> | Hixie: But that's certainly a big part of it. |
| 00:25 | <othermaciej> | I think the problem being solved is "people want to make existing web applications that contain custom controls work with existing accessibility tools without first implementing a major feature in all browsers and then rearchitecting their web apps to use a different approach to custom controls" |
| 00:25 | <webben> | Hixie: the XML events stuff (independence of input devices) is another big part of it; nothing to do with misuse of HTML semantics |
| 00:26 | <webben> | othermaciej: That's certainly how WAI-Roles are being used by Dojo, yes. |
| 00:26 | <Hixie> | webben: what's the problem being solved by XML Events? |
| 00:26 | <othermaciej> | I have no idea what XML Events has to do with it though |
| 00:26 | <webben> | Hixie: accesskey for one thing |
| 00:26 | <othermaciej> | that's just a syntax for attaching event handlers, right? |
| 00:27 | <webben> | othermaciej: the ARIA roadmap tries to explain what these things have to do with one another |
| 00:27 | <Hixie> | (note that i have nothing against stop-gap technologies, i'm only objecting to including wai-role and related stuff in html5 as a long-term solution) |
| 00:27 | <webben> | othermaciej: it's a declarative syntax |
| 00:27 | <webben> | http://www.w3.org/TR/aria-roadmap/#xmlevents |
| 00:27 | <Hixie> | webben: can you describe the problem being solved by xml events in a complete, self-contained sentence? |
| 00:28 | <webben> | Hixie: It seems to me they're trying to solve more than one problem. |
| 00:28 | <othermaciej> | "Having the ability to use XML to integrate listeners and handlers will allow us in in future versions of the XML event specification to tie a descriptive purpose to the handlers." |
| 00:28 | <othermaciej> | this is handwaving nonsense |
| 00:29 | <Hixie> | indeed |
| 00:29 | <webben> | Hixie: e.g. different systems and websites competing for keybindings. |
| 00:29 | <webben> | and e.g. not knowing what functionality a widget has |
| 00:29 | <othermaciej> | the idea of writing a description for an individual event handler for presentation to the user is completely ill-conceived |
| 00:29 | <webben> | what "onclick" actually doers |
| 00:29 | <webben> | *does |
| 00:29 | <othermaciej> | XML Events doesn't solve that problem, and it's not the right problem to solve |
| 00:29 | <othermaciej> | you want to describe the purpose of the button |
| 00:30 | <othermaciej> | not the event handlers the fire when you click it |
| 00:30 | <webben> | othermaciej: with a button, it's trivial |
| 00:30 | <webben> | what about (e.g.) Flickr mouseovers |
| 00:30 | <Hixie> | i still haven't actually heard a description of the problem (other than the one othermaciej quoted, which as he says, is nonsense) |
| 00:30 | <webben> | controls on the web can get very complicated |
| 00:31 | <Hixie> | adding more technology is not a solution to the problem of "controls on the web can get very complicated" |
| 00:31 | <othermaciej> | sure, but you don't want to describe every bit of that complexity |
| 00:31 | <othermaciej> | I'm not sure what use flickr mouseovers would be to a blind user anyway, but it seems like just reading the text that would appear when the user activates the relevant element is more useful than saying that mousing in makes some text appear |
| 00:32 | <webben> | othermaciej: If you look at the example list the roadmap provides, it's quite traditional, e.g. "Submit the form" |
| 00:32 | <webben> | othermaciej: I'm not really sure what you mean there. |
| 00:32 | <othermaciej> | webben: wouldn't the label of the button already describe what it does? |
| 00:32 | <othermaciej> | webben: after all, that's the only info sighted users get |
| 00:33 | <othermaciej> | (barring image buttons, which presumably have alt text for accessibility) |
| 00:33 | <othermaciej> | you want to describe the button to all users |
| 00:33 | <othermaciej> | describing its onclick handlers is pointless |
| 00:33 | <othermaciej> | particularly for things where multiple onclick handlers will apply, it's likely that describing each individually will be far more confusing than just describing the control as a whole |
| 00:34 | <othermaciej> | so both the proposed use for XML Events and the idea that XML Events uniquely addresses that need are wrong |
| 00:35 | <webben> | othermaciej: Like I said, trying to infer anything from the simplest possible case (a button!) doesn't really help. |
| 00:40 | <webben> | I suppose another interesting example would be scrolling and zooming in Google Maps |
| 00:41 | <webben> | othermaciej: re Flickr mouseovers, I do think they would be useful to a blind user and in any case there are plenty of other groups who require device independence (e.g. switch access users) but could /see/ the annotations. |
| 00:43 | <webben> | in complex interfaces, the function of something is not that clear from its label |
| 00:43 | <webben> | e.g. the Firefox bookmarks menu on Linux and Windows (but not Mac) |
| 00:43 | <webben> | right click on a bookmark and you get a context menu where you can edit the bookmark |
| 00:44 | <webben> | left click and you go to the bookmark |
| 00:44 | <webben> | ctrl + left click and you go to the bookmark in a new tab |
| 00:51 | <webben> | othermaciej: re "describing each individually", my impression from the roadmap document is that you would associate multiple triggers with a single "Event" that would be described |
| 00:51 | <webben> | not that all triggers would have to be enumerated to users |
| 00:52 | <webben> | "uniformly integrate event listeners and associated event handlers" |
| 00:53 | <webben> | this gets a bit clearer in the XForms section that follows |
| 00:56 | <othermaciej> | webben: I'd say any action that can only be done through right click is an accessibility problem |
| 00:56 | <othermaciej> | (and, frankly, a usability problem) |
| 00:57 | <webben> | othermaciej: Sure. I'm not sure what you think that implies for what we've been saying though. |
| 00:57 | <othermaciej> | google maps, other than the panning of the map itself, is just a bunch of buttons and a slider |
| 00:57 | <othermaciej> | which could have alt text |
| 00:58 | <webben> | and zooming, and any other custom functionality added by individual developers |
| 00:58 | <webben> | oh and triggering popup markers |
| 00:58 | <webben> | and so on and on |
| 00:58 | <othermaciej> | zooming is the slider I was referring to |
| 00:58 | <othermaciej> | everything else besides the drag-panning just takes an action when clicked |
| 00:58 | <webben> | othermaciej: you can "pan" with the buttons too |
| 00:58 | <othermaciej> | and so is logically a button |
| 00:59 | <webben> | so i'm not sure what you meant by "other than" |
| 00:59 | <othermaciej> | of course, nothing in google maps uses the semantically correct elements even when they could |
| 00:59 | <webben> | well no ... which is rather grist to the mill of Firefox's approach |
| 00:59 | <othermaciej> | yes, you can pan with buttons too |
| 01:00 | <webben> | developers will continue to use divs and spans that they can hack to look good in IE |
| 01:00 | <othermaciej> | why would it be better to advise them to use role="button" on their img elements instead of using a proper button control? |
| 01:00 | <othermaciej> | that can be made to look just as good to IE |
| 01:00 | <webben> | othermaciej: Nobody /does/ advise that. |
| 01:00 | <webben> | (AFAIK) |
| 01:01 | <webben> | it's not (just) about the very best practice, but about accommodating the "real" world. |
| 01:01 | <othermaciej> | sure, but in this case, doing the right thing is in no way harder to do or less compatible than using role |
| 01:02 | <webben> | othermaciej: Good luck convincing Dojo of that. |
| 01:02 | <othermaciej> | Dojo didn't make Google Maps, Google did |
| 01:02 | <webben> | (and Google Maps ... and most of the other div/span Ajax contraptions) |
| 01:03 | <othermaciej> | so far as google maps goes, though, the hard part is making the map data itself useful to a blind user |
| 01:03 | <othermaciej> | not the controls |
| 01:03 | <webben> | othermaciej: Not that hard. We already have one solution for that. (See Raman's work with GMaps in Emacspeak.) |
| 01:04 | <webben> | (it depends on what we mean by map data, I suppose) |
| 01:04 | <webben> | e.g. directions are very simple |
| 01:04 | <webben> | but sorry, I'm drifting off-topic there |
| 01:04 | <othermaciej> | right, I meant the map content with the street layout and labels |
| 01:05 | <othermaciej> | zooming and panning that is pretty unimportant if you can't see the map |
| 01:05 | <webben> | othermaciej: unless you need someone else to see the map |
| 01:05 | <webben> | stuff on the web quickly becomes a social object |
| 01:06 | <webben> | maps and photos become sites of social interaction and sharing and commentary |
| 01:06 | <webben> | (one of the reasons a blind person might be interested in flickr annotations :) ) |
| 01:07 | <webben> | othermaciej: but again XML events is about more than just blind people |
| 01:07 | <othermaciej> | XML events doesn't actually *do* anything though |
| 01:08 | <othermaciej> | it's just XML syntactic sugar for the DOM Events API |
| 01:08 | <othermaciej> | if it might have some feature added in the future then great, but that could just as well be added to the DOM |
| 01:08 | <webben> | (incidentally, there seems to be a misconception in the HTML WG that screen reader users don't use mice at all, but actually mouse control (or failing that mouse keys) is an important mode of interaction with desktop apps) |
| 01:09 | <webben> | othermaciej: I'm not sure there's an ultimate difference between adding things to markup and adding things to the DOM is there? |
| 01:09 | <webben> | othermaciej: surely the key point is not to force UAs to try and guess what scripts do... |
| 01:10 | <othermaciej> | sure, but XML Events has nothing to do with that |
| 01:10 | <webben> | othermaciej: it does when you have event traps for particular key presses (for example) |
| 01:10 | <othermaciej> | but again, a UA should not need to |
| 01:10 | <webben> | the ua can't run the script to work out what pressing F does |
| 01:10 | <othermaciej> | the UA can be made clear to sighted users without annotating scripts for purpose |
| 01:11 | <othermaciej> | er |
| 01:11 | <webben> | do you mean the webapp interface can be made... ? |
| 01:11 | <othermaciej> | s/the UA/a web app/ |
| 01:11 | <webben> | othermaciej: I don't think that's as simple as you imply. |
| 01:11 | <othermaciej> | so if it contains enough info for that, then the key is to encode that info in a way that AT can use |
| 01:12 | <webben> | if you look at a desktop app, it doesn't expose all its functionality and event handling to view |
| 01:12 | <othermaciej> | why does a blind user need to know what right clicking on a random element will do more than I do? |
| 01:12 | <webben> | this is increasingly true of web apps too |
| 01:13 | <webben> | othermaciej: Out of context, that's an impossible question to answer. It depends what right clicking does... |
| 01:13 | <othermaciej> | well, I don't know without trying it |
| 01:13 | <othermaciej> | I assume that by convention it would display a context menu unless some sort of instruction told me otherwise |
| 01:13 | <webben> | othermaciej: how do you try it if you can't right-click? |
| 01:14 | <othermaciej> | webben: presumably AT would have a feature to context-click a chosen element |
| 01:14 | <webben> | othermaciej: Indeed it might. But that's not necessarily the same as right-clicking in a webapp. |
| 01:15 | <webben> | e.g. i can press shift + f10 in Fx to open a context menu |
| 01:15 | <othermaciej> | (one difficulty there is that generally everything would have a context menu so you can't limit it to only some items) |
| 01:15 | <webben> | but that wouldn't get caught by a script checking for right mouse clicks |
| 01:15 | <webben> | so my impression is that XML events would be used to separate commands (what you can actually do) from triggers (what you can do to accomplish commands) |
| 01:16 | <othermaciej> | XML events doesn't actually do that though |
| 01:16 | <othermaciej> | (although there is a <command> element in HTML5 that does) |
| 01:16 | <Lachy> | wow, Bible5 is a great idea! :-) I think it'll be a great opportunity to deal with the lack of interoperability between scientists and creation scientists. |
| 01:17 | <othermaciej> | won't we also need Scientific Method 5? |
| 01:17 | <othermaciej> | or would Bible5 support both rational and faith-based serializations? |
| 01:18 | <webben> | lol |
| 01:19 | <Hixie> | faith-based interaction will be non-conforming, though supported for back-compat |
| 01:21 | <Lachy> | I don't think so. The faith based serialisation would claim the existence of the almighty Hickson without any empirical evidence to support their claim. The rational based serialisation would claim that since the only evidence we have for his existence is hearsay, and so we must remain agnostic to his existence. |
| 01:23 | <Hixie> | good lord, let's not try to posit my omniscience |
| 01:24 | <Lachy> | the problem is that simply claiming that bible5 is the infallible word of Hixie doesn't constitute evidence. |
| 09:16 | Hixie | is deep in the encoding stuff getting his hands very dirty |
| 09:55 | <Hixie> | hah, Lachy is trying to get me in trouble :-P |
| 12:28 | <annevk> | got to love bible5 |
| 12:38 | <annevk> | whoa, IE people on the public-html list! |
| 12:38 | <annevk> | hurray |
| 12:39 | <Lachy> | has Chris been the only MS guy on the list until now? |
| 12:40 | <annevk> | think so |
| 12:40 | <annevk> | but this question is related to implementations, nice step forward from previous discussions |
| 12:43 | <annevk> | selectAllElements is long |
| 12:44 | <annevk> | but I suppose it's sort of acceptable |
| 12:44 | <annevk> | selectElement is too, but not as long and cumbersome to type as getElementById |
| 12:44 | <Lachy> | I know, but it doesn't have too many uppercase letters in it, so it's not too hard to type |
| 12:48 | <annevk> | hmm UTF-32 is dropped |
| 12:49 | <annevk> | don't think we'll drop it though |
| 12:50 | <Lachy> | hmm. is UTF-32 freqently misimplemented any more than UTF-8 and UTF-16? |
| 12:55 | <Lachy> | would anyone like to help write some examples for selectors api? I need to revise the one marked as an issue in the spec and I should provide a demonstration of using the default namespace |
| 12:55 | <Lachy> | any idea of a use case where it is useful to specify a default namespace? |
| 12:56 | <annevk> | pointer? |
| 12:56 | <Lachy> | http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?content-type=text/html;%20charset=utf-8 |
| 12:57 | <annevk> | It's interesting how it went from WHATWG's HTML5 to W3C's HTML5 http://blog.codedread.com/archives/2007/06/22/mollys-grenade/ |
| 12:58 | <annevk> | http://ccapeng.blogspot.com/2007/06/html-required-fields.html is weird |
| 12:58 | <annevk> | Maybe we shoul review WCAG? |
| 12:59 | <annevk> | hmm, people are also referring to the html4-differences doc as the draft spec for html5... |
| 12:59 | <Lachy> | lol |
| 12:59 | <webben> | Well, screen readers will support the later and not the former. |
| 13:00 | <annevk> | seems pretty pointless |
| 13:00 | <webben> | but will hopefully support both in future |
| 13:00 | <annevk> | especially since setAttributeNS is not supported by IE |
| 13:00 | <webben> | annevk: it doesn't matter since the target screen readers can use Fx. |
| 13:01 | <webben> | basically the only advantage of continuing to use IE is that Adobe can't be bothered to support Fx properly |
| 13:01 | <webben> | (for Flash content) |
| 13:01 | <annevk> | would be nice if these screen reader people got involved in html5 |
| 13:02 | <webben> | (well, or if you use Dolphin or BAUM or Thunder screen readers) |
| 13:02 | <annevk> | might save them some trouble in the future |
| 13:02 | <webben> | since those are still IE-dependent |
| 13:02 | <webben> | annevk: Yes. I've been saying that for some time. |
| 13:03 | <webben> | annevk: I think they're actually terribly busy though. |
| 13:03 | <webben> | they tend to have very few staff and to be busy to dealing with a lot of non-web related stuff |
| 13:03 | <webben> | e.g. Vista |
| 13:03 | <annevk> | did you tell them? |
| 13:03 | <webben> | or e.g. basic functionality in the case of FOSS screen readers |
| 13:03 | <annevk> | Lachy, hmm... not really |
| 13:03 | <webben> | annevk: i did a post to the mozilla accessibility-dev list a few weeks ago |
| 13:04 | <annevk> | Lachy, namespaces are in there for correctness, not because they have much use cases on the web... |
| 13:04 | <webben> | annevk: I've been thinking about doing something similar with GW-Micro |
| 13:04 | <annevk> | webben, cool |
| 13:04 | <annevk> | go for it! :) |
| 13:04 | <Lachy> | annevk: I realise that, that's why I can't think of any |
| 13:04 | <webben> | unfortunately there's no "official" Freedom Scientific list |
| 13:06 | <webben> | at the very least, they would be able to correct misconceptions like the idea that screen reader users don't use mice |
| 13:07 | <annevk> | hmm, we need to finish this C impl of the HTML5 parser if we want to make this web survey thing happen with "reproducable" results |
| 13:07 | <webben> | I did manage to persuade GW-Micro to put their release history (basically the readme file for each version) online, which should help. |
| 13:07 | <webben> | annevk: web survey thing? |
| 13:07 | <Lachy> | oh, perhaps I could add an XBL fragment to the head of an XHTML document, and then use selectElement("div", res); with the default NS as XHTML, so that I don't select <div> from the XBL NS instead. |
| 13:08 | <annevk> | finding out what is being used out there without relying on Google to provide sanitised numbers |
| 13:08 | <annevk> | Lachy, XBL is a nice example |
| 13:09 | <annevk> | Lachy, you need to fix up the conformance criteria btw |
| 13:09 | <webben> | annevk: Cool. Glad to hear there's a project to do that. But we really need qualitative studies too. |
| 13:09 | <Lachy> | annevk: what's the specific issue? |
| 13:09 | <annevk> | webben, what project? |
| 13:09 | <annevk> | Lachy, "conforming documents" |
| 13:09 | <webben> | annevk: provide numbers. |
| 13:09 | <annevk> | and authoring tools... |
| 13:10 | <annevk> | webben, well, so far there's only the project Hixie does |
| 13:10 | <annevk> | I'd like to have a second, open one |
| 13:10 | <webben> | annevk: Yeah, that would be neat. |
| 13:11 | <Lachy> | do you mean that "One that produces conforming documents." isn't a good defintion of a conforming authoring tool? |
| 13:11 | <webben> | What I've been wondering is whether one could use the WayBack archive somehow. |
| 13:11 | <webben> | as a readily available cache |
| 13:11 | <annevk> | Lachy, I'm not sure they make much sense |
| 13:11 | <webben> | i dunno |
| 13:11 | <Lachy> | ok, I'll think about it |
| 13:11 | <annevk> | better to scrape live sites |
| 13:12 | <webben> | I wonder how one would deal with the issues around public cacheing that webcitation and WayBack have to deal with |
| 13:12 | <webben> | (re removing stuff from the cache when domain owners request it for example) |
| 13:14 | <Lachy> | perhaps I should rename "conforming document" to a "conforming script" instead, and then define conforming authoring tool as a tool that produces conforming scripts. |
| 13:14 | <Lachy> | or s/script/application/ |
| 13:14 | Lachy | doesn't know |
| 13:14 | <annevk> | webben, it's not about caching, it's just about running algorithms on those documents and publishing the results; I don't think we'd cache them, but it's far from finished anyway |
| 13:14 | <annevk> | our current tools are good enough to survey about 2500 sites... |
| 13:15 | <annevk> | in a reasonable time |
| 13:15 | <webben> | annevk: Well you'd want to be able to cache them in order to qualify the results. |
| 13:15 | <annevk> | Lachy, that might work, or just have conforming user agents |
| 13:15 | <annevk> | webben, I don't understand |
| 13:15 | <webben> | e.g. so we've got a load of table elements or summary attributes, but then what are these actually being used for? |
| 13:16 | <annevk> | oh, you could store the URLs I suppose |
| 13:16 | <webben> | annevk: But that's not reproducible. |
| 13:16 | <annevk> | that's not really a concern right now anyway |
| 13:16 | <webben> | Well, I guess it is reproducible to some extent actually. |
| 13:17 | <webben> | but it's a changing phenomenon |
| 13:17 | <Lachy> | hmm. I see XHR only has conforming UA as well |
| 13:17 | <webben> | Lachy: I can't see any other way then to talk about producing conforming documents/apps for a document/app spec. |
| 13:18 | <annevk> | annoying, http://xhtml.se/ gives a parse error |
| 13:18 | <webben> | Lachy: Authoring tools might have to conform to other things (e.g. ATAG) in order to produce conforming docs in the first place though |
| 13:18 | <annevk> | (fortunately Opera has "reparse as HTML" ...) |
| 13:19 | <webben> | annevk: yeah it's a good feature :) |
| 13:19 | <webben> | be nice if browsers had that for other things |
| 13:19 | <annevk> | unescaped & |
| 13:19 | <webben> | e.g. open a word document and get the option to parse it into HTML |
| 13:19 | <annevk> | it would be nice if XML had sane error handling |
| 13:19 | <webben> | or PDF |
| 13:20 | <annevk> | that would be a different feature |
| 13:20 | <webben> | It's true it wouldn't be error handling. :) |
| 13:20 | <annevk> | "parse as HTML" is just feeding the exact same byte stream in an HTML parser |
| 13:21 | <annevk> | nothing to do with conversion |
| 13:21 | <webben> | annevk: I'd say that is conversion of sorts. |
| 13:21 | <annevk> | whatever |
| 13:35 | <annevk> | application/html?! |
| 13:35 | <annevk> | hah |
| 13:36 | <Lachy> | annevk: do you think sam ruby was being serious with that suggestion? I couldn't tell |
| 13:36 | <annevk> | he proposed application/xhtml at some point on his blog |
| 13:36 | <annevk> | I'm not sure why he thinks deploying a new MIME type would work and why we want to do it in the first place though |
| 13:37 | <annevk> | it violates all kinds of design principles |
| 13:37 | <Lachy> | doesn't he understand that they already tried the approach of changing MIME type with application/xhtml+xml, and that has so far failed |
| 13:37 | <annevk> | dunno |
| 13:37 | <annevk> | I guess I'll just ignore it for now |
| 13:37 | <annevk> | Don't want to get involved in the versioning debate |
| 13:38 | <annevk> | you got an interesting response to your longdesc thingie as well |
| 13:38 | <annevk> | lol |
| 13:38 | <Lachy> | the one from steve faulkner? |
| 13:39 | <annevk> | the one that said "who cares if it's useless" |
| 13:39 | <Lachy> | yeah, I didn't get that, since that is a self defeating argument. That's why I assumed he meant who care's if it's used, which makes more sense in the context |
| 13:44 | <annevk> | It seems that the accessibility people get upset because the draft doesn't change on a whim |
| 13:45 | <annevk> | "And why should we bother? There has been a lot of efforts made previously by John (Folliot) and others in order to save summary and headers in tables. Still, the draft hasn't backed out one bit on the subject." |
| 13:45 | <Lachy> | they get upset when someone disagrees with them, or tries to achive the same result using a different method |
| 13:45 | <Lachy> | see my response to that, I think I explained the situation well enough |
| 13:47 | <annevk> | yeah, seems like it |
| 13:47 | <annevk> | we tried that before though |
| 13:47 | <annevk> | it's quite hard to get through |
| 13:48 | <webben> | Lachy: actually looks to me reading that like he meant "who cares if it's used" |
| 13:48 | <webben> | but i dunno |
| 13:48 | <webben> | the notion that screen readers are only just implementing longdesc is wrong |
| 13:49 | <webben> | window-eyes has supported it since at least 4.5; JAWS since around 4.01 |
| 13:49 | <Lachy> | what about HPR? |
| 13:49 | <webben> | Lachy: that's abandonware |
| 13:49 | <webben> | but I'll try and find out |
| 13:49 | <Lachy> | oh, I didn't know |
| 13:50 | <webben> | Lachy: I'm trying to find out whether there's anyway to get HAL to support it (HAL isn't abandonware) |
| 13:50 | <Lachy> | I don't use screen readers, cause they're so damn difficult to use and they don't provde a good web developer versions |
| 13:50 | <webben> | Lachy: what would a good webdev version be? |
| 13:51 | <webben> | (and how can it get better than free or bundled versions e.g. Orca, NVDA, VoiceOver) |
| 13:51 | <Lachy> | one that's free and features tools that a useful for web developers to test pages |
| 13:51 | <webben> | Lachy: I'd go with the ICITA firefox accessibility extension (simply awesome) + Window-Eyes demo |
| 13:51 | <webben> | (30 minutes per Windows session) |
| 13:51 | <annevk> | you shouldn't have to test AT software |
| 13:51 | <Lachy> | does that mean I need to restart every 30 minutes to keep using it? |
| 13:52 | <webben> | Lachy: yes ... 30 minutes is quite a long time in practice; and restarting is fast if you're using Win in a VM |
| 13:52 | <webben> | (and really, there's no other way to use Win ;) ) |
| 13:52 | <webben> | the bore is JAWS, which is available in a demo version whose EULA forbids webdevs from using it for testing |
| 13:52 | <Lachy> | no, that's unacceptable. I tried it with the JAWS 40 min trial before, and it was so annoying |
| 13:53 | webben | shrugs. I test like that all the time. |
| 13:53 | <webben> | but like I say, there are lot of free options |
| 13:53 | <Lachy> | the other problem is usability. I want a screen reader built for people who can see, that is designed for testing with |
| 13:54 | <webben> | Lachy: I think that would largely defeat the point. |
| 13:54 | <webben> | It's key to understand how screen reader users use webpages. |
| 13:54 | <webben> | Not just have a tech that reads the page to you. |
| 13:55 | <Lachy> | no, not if it simulated it without hijacking my keyboard shortcuts |
| 13:55 | <webben> | in any case, Window-Eyes has plenty of visual interface |
| 13:55 | <webben> | e.g. the list of links |
| 13:55 | <webben> | Lachy: Well that's useful too. Alerts people to the fact that Ajax shortcuts may conflict with AT. |
| 13:55 | <webben> | ditto VoiceOver also has a visual list of items and links |
| 13:56 | <Lachy> | Ajax shortcuts are annoying anyway, especially if they interfere with find-as-you-type |
| 13:56 | <webben> | Indeed, and that wouldn't be as obvious if you had a Firefox simulation that behaved just like IE ;) |
| 13:57 | <webben> | remove the interface from the screen reader, and it becomes much less valuable as a testing tool; might as well just comply with the guidelines |
| 13:57 | <webben> | but in any case there are plenty of testing tools that don't interfere with shortcuts |
| 13:57 | <webben> | including the ICITA extension I mentioned and Fangs |
| 13:58 | <Lachy> | it doesn't have to remove it completely, just provide a way for me to enable it when I need it and easiily disable it when I don't. |
| 13:58 | <webben> | Lachy: how about turning the reader off and turning it on again? |
| 13:58 | <Lachy> | takes too long |
| 13:58 | <webben> | (again, I do that all the time with VO, there's even a keyboard shortcut for it) |
| 13:59 | <Lachy> | enabling/disabling the UI should be instantaneous |
| 13:59 | <webben> | Lachy: well, it takes time, there's no way around having to load the speech capabilities. |
| 13:59 | <webben> | the only case where I think that's a valid criticism is Fire Vox, where there's no quick way to turn it of and on. |
| 13:59 | <webben> | afaik |
| 14:01 | <Lachy> | well, my experience with JAWS was terrible. The UI was so difficult to understand and figure out. After several hours searching through documentation, I still never found, for example, how to get it to read a title attribute |
| 14:01 | <webben> | Lachy: A |
| 14:02 | <webben> | ah yes, you want the shortcut key for extended element information |
| 14:02 | <Lachy> | but even tasks that should be simple, like controlling where it should read and stop reading. |
| 14:03 | <webben> | did you look at the list of keyboard shortcuts? |
| 14:03 | <Lachy> | nah, I won't use it anyway as long as they keep the stupid time limits |
| 14:03 | <webben> | Lachy: insert + shift +f1 and ctrl+ ins + shift + F1 for extended element info |
| 14:04 | <Lachy> | yikes! |
| 14:04 | <webben> | ctrl to interrupt speech is probably what you want |
| 14:04 | <webben> | Lachy: if you think you've got keyboard shortcut problems ... ;) |
| 14:05 | <webben> | Lachy: the Windows-Eyes demo you can mouse around a lot though |
| 14:05 | <Lachy> | ok, whatever |
| 14:06 | <webben> | I agree the documentation could be improved. OTOH the documentation for browsers is horrific too. |
| 14:06 | <Lachy> | at least browsers are somewhat intuitive |
| 14:06 | <webben> | (actually in fairness Opera isn't too bad from what I've seen) |
| 14:06 | <webben> | Lachy: Not really. |
| 14:06 | <Lachy> | what's not intuitive? |
| 14:06 | <webben> | they're heavily reliant on people being familiar with WIMP interfaces |
| 14:06 | <webben> | screen readers are heavily reliant on other forms of familiarity |
| 14:06 | <Lachy> | WIMP? |
| 14:07 | <webben> | windows-icon-mouse-pointer |
| 14:07 | <webben> | *familiarity with other things, rather |
| 14:07 | <annevk> | ah, authors should not use UTF-32 |
| 14:07 | <Lachy> | well, that's sort of my point from earlier. Design a screen reader for WIMP interfaces, aimed at web devs who can see, and it would really help |
| 14:08 | <webben> | Lachy: I can't see how that would work. |
| 14:08 | <webben> | lots of new navigation options in a menu? |
| 14:08 | <annevk> | would be fun if someone from us made a comparison of XHTML2 and XHTML5 too |
| 14:09 | <Lachy> | instead of requiring keyboard shortcuts to control everything, provde clearly labelled aon screen menus, buttons, etc. that simulate the keyboard shortcuts |
| 14:09 | <Aidan_> | Hi |
| 14:09 | <Lachy> | s/aon/on/ |
| 14:09 | <webben> | Lachy: well i suppose you could build an Fx extension to do that |
| 14:09 | <webben> | Lachy: you might suggest it to the ICITA folks |
| 14:10 | <Lachy> | I'll have to look at what they provide first |
| 14:10 | <webben> | although I guess that doesn't handle the reading out loud aspect |
| 14:10 | <webben> | Oh I'd definitely take a look if you haven't already. |
| 14:10 | <Lachy> | what do you mean? why wouldn't it? |
| 14:10 | <webben> | Lachy: ICITA doesn't read the text. |
| 14:10 | <Lachy> | then what does it do? |
| 14:10 | <webben> | it provides navigational and testing tools |
| 14:10 | <annevk> | hi Aidan_ |
| 14:10 | <webben> | it's easier to see than explain |
| 14:11 | <Philip`> | In terms of doing surveys of 2500 sites in "a reasonable time", that's partly limited by me considering half an hour to be 'a reasonable time' and not wanting to bother waiting much longer ;-) |
| 14:12 | <Aidan_> | I want join to whatwg where i can do that? |
| 14:12 | <annevk> | half an hour is reasonable |
| 14:12 | <Lachy> | why does it take that long? |
| 14:12 | <annevk> | Aidan_pl, http://www.whatwg.org/mailing-list#specs |
| 14:12 | <Lachy> | is it because you're computer is slow, or because python can't process the pages too quickly? |
| 14:13 | <Philip`> | Also I need to update my tools to stop using SQLite to download pages into, because it keeps aborting with locked-database exceptions and I have to keep manually fixing it... |
| 14:13 | <annevk> | Aidan_pl, you can also contribute on the forums (forums.whatwg.org) or by writing blogposts etc. |
| 14:13 | <annevk> | Philip`, that sounds annoying |
| 14:14 | <Philip`> | I can't actually remember how long it took - might have been quite a bit less than half an hour |
| 14:14 | <annevk> | Philip`, maybe we could set up some kind of distributed computing with all members of the mailing list and have everyone run the script :) |
| 14:14 | <webben> | I was about to suggest that. |
| 14:14 | <webben> | if the only factor is bandwidth/time |
| 14:14 | <Philip`> | but mostly it just takes a while to download all the pages (even doing lots in parallel), and then takes a longer while to parse them all (which can't be done in parallel when I only have one processor) |
| 14:15 | <Philip`> | I have plenty of bandwidth here, so that part isn't a problem :-) |
| 14:15 | <Lachy> | annevk: I've an idea for a while to write a FF extension that does surveys on pages as the user surfs the web, and then submits it all to a central server later |
| 14:15 | <Philip`> | The other main problem is getting a list of pages to look at |
| 14:15 | <annevk> | Philip`, doesn't Y! or some such provide a URL generator? |
| 14:16 | <Philip`> | since the results will be significantly biased by however that list is gathered |
| 14:16 | <webben> | annevk: a URL generator? |
| 14:16 | <webben> | generating based on what? |
| 14:16 | <Philip`> | annevk: I couldn't find anyone that had a way of getting a random URL; and random probably isn't very good, since it ought to be weighted towards the pages that people look at frequently |
| 14:17 | <Philip`> | (or, couldn't find anyone that had a way of getting a random URL from a sufficiently large collection) |
| 14:18 | <annevk> | Lachy, hmm, with html5lib in it? :) |
| 14:18 | <Lachy> | possibly |
| 14:18 | <webben> | I'm not sure that is necessarily a great way of weighting thing. |
| 14:18 | <Lachy> | if it's possible to execute python in an FF extension |
| 14:18 | <webben> | e.g. a scientific paper is not necessarily a tiny fraction of the importance of the Digg front page |
| 14:19 | <Lachy> | otherwise, it could either use a parser written in JS or just read the DOM from the browser |
| 14:19 | <webben> | it's probably a lot more helpful to have different weights by context |
| 14:19 | <annevk> | I think that's known webben |
| 14:19 | <webben> | e.g. to know that scientific papers tend to use a given sort of markup, and personal homepages another |
| 14:19 | <annevk> | If you have a better suggestion please tell it |
| 14:20 | <webben> | annevk: Well, one could actually (for example) poll HTML links from connotea or something. |
| 14:20 | <Lachy> | the only issue with that would be privacy, since you probably wouldn't want it surveying pages on intranets or in secure sites that the user visits, since it would submit the URI with the data |
| 14:20 | <Philip`> | I remember there being one survey done on most of the sites in http://dmoz.org/ |
| 14:20 | <Philip`> | (Only 'most' because they ran out of time at the end) |
| 14:21 | <annevk> | doesn't google base provide some type of index too? |
| 14:21 | <webben> | all now dmoz would help categorize stuff |
| 14:22 | <webben> | possibly delicious could too |
| 14:22 | <Philip`> | Maybe it would be not entirely useless to start with some list of sites, and then make a simple spider so it can get loads more (less biased towards front pages) |
| 14:22 | <webben> | Philip`: I suppose you could actually categorize things by the number of / in the URL |
| 14:22 | <Philip`> | And perhaps it'd be worthwhile to collect statistics based on lists of pages gathered from different sources, and see how much difference there is between them, to show how much the page selection affects the results |
| 14:23 | <webben> | yeah |
| 14:23 | <Lachy> | Philip`: if you've got a tool written that I can easily set up and run, I'd be happy to let it run on my computer for a few days straight. It should be able to get through a 60,000 pages overnight |
| 14:24 | <Lachy> | the only issue would be bandwidth |
| 14:24 | <Philip`> | You'd probably find it hits that page with a megabyte of numeric entities that make html5lib take quadratic time to parse, and it'd be stuck there for the whole time :-p |
| 14:26 | <Philip`> | The 2500 pages I looked at were about 100MB in total, so that's 40KB average, which probably indicates how many you could download |
| 14:26 | <annevk> | hmm |
| 14:27 | <Lachy> | so 50,000 would be about 2GiB. That's reasonable |
| 14:27 | <annevk> | numeric entity parsing does some conversion stuff that might slow Python down |
| 14:27 | <Philip`> | (In a perfect world where I didn't have too many other things to do already, it would be nice to download attached JavaScript and CSS files to see if there's interesting stuff that comes from analysing those) |
| 14:28 | <Lachy> | would it be reasonable to disable char ref parsing and just have it emit U+FFFD for all of them? Would they be relevant to the results? |
| 14:28 | <Lachy> | it depends what the survey is looking for |
| 14:28 | <Philip`> | annevk: I believe it was the concatenation onto a text node that was quadratic, in the minidom implementation - maybe other tree builders will work better |
| 14:29 | <annevk> | oh ok |
| 14:29 | <annevk> | so not the actual entity parsing |
| 14:29 | <webben> | Lachy: yes you do want to actually read the text (e.g. find out what attributes are use for) |
| 14:29 | <webben> | *used |
| 14:30 | <Philip`> | It'd probably be good just to have a timeout on the parser |
| 14:30 | <Lachy> | webben: yeah, that's why I said it depends what the survey is for. If it was just to see how many times a particular element occurs, without caring about it's actual content, then it wouldhn't matter |
| 14:30 | <Philip`> | I don't expect html5lib is that happy when I try parsing PDF files with it, though at least it didn't break horribly in the cases I encountered |
| 14:31 | <Philip`> | (Also, I didn't handle character encoding at all, so I really need to fix that...) |
| 14:31 | <webben> | I think information on frequency isn't worth collecting. |
| 14:31 | <Lachy> | doesn't it check the MIME and only parse text/html files? |
| 14:31 | <webben> | (well, not /just/ frequency anyhow) |
| 14:34 | <annevk> | we should check and log Content-Type |
| 14:35 | <annevk> | maybe also implement the sniffing for text/html so we can determine whether the page is a feed or not |
| 14:38 | <Philip`> | I wasn't checking HTTP headers at all |
| 14:39 | <webben> | Lachy: Why would a blank longdesc imply that it's "used incorrectly"? Surely that would just imply there is no long description for the image? |
| 14:39 | <Philip`> | though I've got another fork of the downloading script which does save them, since I was looking for mobile sites that actually used XHTML |
| 14:39 | <Lachy> | well, it's certainly not used in a useful way |
| 14:39 | <webben> | Lachy: That's not the same thing. |
| 14:39 | <annevk> | webben, actually, blank means that it references the same URI as the page iirc |
| 14:40 | <Lachy> | webben: usefulness is what really matters |
| 14:40 | <Lachy> | incorrect values and empty values are both useless |
| 14:41 | <webben> | Lachy: Empty values doesn't tell you much about the utility of an attribute. |
| 14:41 | <Lachy> | as are links to description pages that aren't really long descriptions of the image |
| 14:41 | <Philip`> | An HTML5-compatible web page downloading thing (content-type sniffing, working out charset based on HTTP headers, resolving and following links, etc) in Python would be quite handy |
| 14:41 | <Lachy> | an empty value just means that it's a usage that shouldn't be counted as useful |
| 14:41 | <webben> | Lachy: What would tell you something is finding web pages with good long descriptions of images and seeing if they make any use of longdesc. |
| 14:41 | <webben> | And trying to find out, if they don't, why. |
| 14:42 | <annevk> | Lachy, not in theory |
| 14:42 | <Lachy> | webben: what the? |
| 14:42 | <webben> | (e.g. it might be because they're using <a> links after the image, for reasons of poor UA or AT support) |
| 14:42 | <annevk> | <img src> could in theory work if the browser gave a different Accept header when requesting the image resource |
| 14:42 | <webben> | or because they got a particular sort of usability advice about it. |
| 14:42 | <annevk> | in practice I suppose it doesn't work at all unless there's some base URI |
| 14:43 | <webben> | Lachy: In other words, you need to look at examples where longdesc should have (and realistically could have) been used. |
| 14:43 | <Lachy> | webben: how would you suggest finding such pages? |
| 14:43 | <Lachy> | unless you find them by looking for the presence of the longdesc attribute, you're just looking for a needle in a haystack |
| 14:44 | <Lachy> | one example I know of that uses links to long descriptions is the CSS 2.1 spec |
| 14:44 | <webben> | Lachy: Well, pages that don't use the longdesc attribute but should have done, or did but used it wrong, are what you're trying to measure. Just looking for the attribute itself doesn't tell you about the former. |
| 14:45 | <Lachy> | webben: but then there's still the question of how you find the pages that should have but didn't? |
| 14:45 | <annevk> | <base href=foo><img longdesc> would create issues |
| 14:46 | <webben> | Lachy: I didn't say it was easy. But there's no point replacing relevant qualitative research with meaningless statistics just because it's easier. |
| 14:46 | <webben> | Lachy: I'd be tempted to look at things like British Museum's Compass. |
| 14:47 | <webben> | (which probably doesn't use longdesc but i dunno) |
| 14:47 | <Lachy> | webben: it really doesn't matter if pages should have used it but didn't, because we're interested in cases where it does get used and get used properly. Although, pages that don't use it but should have are evidence that the attribute has failed and should be dropped. |
| 14:47 | <webben> | i.e. big organizations with disability commitments and interesting images to show |
| 14:47 | <Aidan_pl> | I'm have problem with HTML5 |
| 14:48 | <webben> | Lachy: They aren't evidence of that necessarily at all. |
| 14:48 | <zcorpan> | Aidan_pl: ok |
| 14:48 | <Lachy> | then what would they be evidence of? |
| 14:48 | <annevk> | Aidan_pl, join the club :) |
| 14:49 | <webben> | Given how tied it is to how well or badly a specification specified the attribute, what guidance confused the issue, how poorly UA developers bothered to consider accessibility, how knowledgable and determined AT developers were to get at the attribute anyhow |
| 14:49 | <webben> | and the complex interaction of such factors |
| 14:49 | <Aidan_pl> | I set doctypelike that: <!DOCTYPE html> and validated http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fwww.ligagothic.ovh.org%2Findex.php what is wrong? |
| 14:49 | <webben> | (there's a lot of feedback in such processes) |
| 14:49 | <Lachy> | webben: that would all be evidence of it's failure in the real world |
| 14:50 | <webben> | No it wouldn't. |
| 14:50 | <Lachy> | yes it would |
| 14:50 | <webben> | Why? |
| 14:50 | <zcorpan> | Aidan_pl: there's a comment before the doctype. although that is allowed in the spec now. |
| 14:50 | <annevk> | Aidan_pl, that's a bug in the validator I believe |
| 14:50 | <Lachy> | if it was so poorly specced, poorly implemented, never used, not understood; it has failed. It's as simple as that! |
| 14:50 | <annevk> | Aidan_pl, since the specification is work in progress the validator is not always up to date |
| 14:51 | <webben> | Lachy: Well it's true that the process might have failed once. That doesn't mean you can't restart the process in such a way as to succeed. |
| 14:51 | <Lachy> | webben: there's no point trying to beat a dead horse |
| 14:51 | <webben> | (in fact, failure can often lead to a more successful process the second time round) |
| 14:51 | <Lachy> | it ain't going to go anywhere |
| 14:51 | <Philip`> | Lachy: Nice choice for selector names ;-) |
| 14:51 | <webben> | Lachy: I don't find proverbs to be particularly persuasive. |
| 14:52 | <webben> | Lachy: Actually, there's plenty of reasons to expect change in the web sphere. |
| 14:52 | <webben> | increasing competition, increasing accessibility awareness among them |
| 14:52 | <webben> | rising professional standards |
| 14:52 | <Lachy> | webben: a better solution would be to look at the problem that needs to be solved and find a solution that would be successful, instead of trying to drag an unsuccessful solution through. |
| 14:52 | <webben> | more digitization of important collections |
| 14:53 | <webben> | Lachy: You need to distinguish between the attribute and the process. |
| 14:53 | <Lachy> | what the? |
| 14:53 | <annevk> | I actually think that <a><img></a> or something similar is better than longdesc |
| 14:53 | <webben> | Otherwise your analysis will be hopelessly flawed. |
| 14:53 | <annevk> | a description of the image is useful for everyone |
| 14:54 | <webben> | annevk: UAs can expose it if they want. |
| 14:54 | <webben> | but you don't always want to show the description as a link |
| 14:54 | <webben> | annevk: indeed extensions have been written to UAs to expose it |
| 14:54 | <annevk> | yes, I'm aware of that |
| 14:55 | <webben> | Lachy: there's a huge difference between the conception, the potential of a HTML attribute and the practicalities of getting people using it: the second is a process. |
| 14:56 | <webben> | The failure of the process often tells you nothing about the conception or potential of the attribute. |
| 14:57 | <Lachy> | the failure of the process tells you everything. If people still don't use it propelry after 10 years, there's little hope |
| 14:57 | <webben> | Lachy: No. It's like the difference between a great invention and actually getting it to market. |
| 14:57 | <Aidan_pl> | Is Firefox support to HTML 5? |
| 14:58 | <webben> | Market dominance is not linearly correlated with technical excellence. |
| 14:58 | <Lachy> | Aidan_pl: it supports some featurs from HTML5 already |
| 14:58 | <Lachy> | Aidan_pl: e.g. <canvas>, <a ping=""> |
| 15:00 | <Lachy> | webben: do you honestly think that longdesc="" is an example of technical excellence? |
| 15:00 | <webben> | e.g. the fact that it's taking an absurdly long time to get basic CSS selectors implemented doesn't mean such selectors are hopeless |
| 15:00 | <annevk> | Aidan_pl, browsers are incrementally evolving; at some point they will be there |
| 15:01 | <webben> | Lachy: I don't see anything wrong with longdesc whatsoever actually. What do you think it's technical flaw is? |
| 15:01 | <webben> | I see more problems with alt= |
| 15:02 | <webben> | (since you can't indicate changes of language within alt, for instance) |
| 15:02 | <Lachy> | it's techincal flaw is that it's an accessibility add-on that requires additional effort from authors, instead of being part of it's fundamental design and use |
| 15:02 | <webben> | Lachy: That's not a technical flaw. And it's not surmountable. |
| 15:02 | <webben> | Accessibility requires some effort. That is not a technical flaw. |
| 15:02 | <webben> | Usability requires some effort. That's not a flaw either. |
| 15:03 | <webben> | ditto design etc |
| 15:03 | <Lachy> | A good goal is to make accessibility require as little effort as possible to get right |
| 15:03 | <webben> | Lachy: Of course. Those aren't contradictory ideas. |
| 15:03 | <webben> | Ditto design, usability etc :) |
| 15:03 | <webben> | Doesn't mean you can magic away the effort of providing alternatives. |
| 15:04 | <webben> | Or the effort of not confusing the user with an overly complicated interface, or of not making your website look ugly. |
| 15:05 | <webben> | Computers can't magically describe images for us (yet). |
| 15:06 | <webben> | They might one day be able to convert text to sign language and similar transformations though |
| 15:06 | <webben> | (there's been some experimentation with S.L. avatars) |
| 15:09 | Aidan_pl | want know is ther any person from poland |
| 15:16 | <webben> | "If the alt attribute is omitted, user agents must treat the element as if it had an alt attribute set to the empty string." ... that is not a good idea. UAs should expose the difference between no alt and alt="" to AT. |
| 15:17 | <webben> | In the former instance, the AT can do something helpful like try and guess alternative text from the src URI or at least provide the opportunity to label the image. |
| 15:17 | <webben> | (this is in fact what AT do now) |
| 15:18 | <webben> | although the guessing tends to be a bit rubbish |
| 15:37 | <Lachy> | webben: I believe that argument has been made against treating no alt the same as atl="". Though, I'm not sure why Hixie decided to handle it that way anyway. |
| 15:37 | <webben> | it's completely unimplementable AFAICT |
| 15:38 | <Lachy> | why? |
| 15:38 | <Lachy> | because it would break existing pages? |
| 15:38 | <webben> | of course |
| 15:38 | <webben> | because that's how AT does handle alt without "" |
| 15:38 | <webben> | sorry img with alt |
| 15:38 | <webben> | it's not some theoretical process |
| 15:39 | <webben> | (and a lot of pages don't have alt attributes) |
| 15:39 | <Lachy> | do all ATs do it that way? |
| 15:39 | <webben> | all the ATs I've come across do something like that yes |
| 15:40 | <webben> | but you can probably configure some to do something different |
| 15:40 | <webben> | Lachy: Also it gets a bit more complicated when an img is the sole content for the link |
| 15:40 | <webben> | IIRC sometimes the URL of the link will be read instead. |
| 15:43 | <Lachy> | how do ATs handle empty links, like <a href="foo"></a>? I've seen pages do that and then use CSS to size and position them over the top of images to create a sort of image map |
| 15:44 | <webben> | Lachy: I don't know. I'd have to test that. |
| 15:45 | <webben> | Lachy: http://www.freedomscientific.com/fs_products/Surfs_Up/Custom_Labels.htm example of image labelling with a screen reader |
| 15:45 | <webben> | (though that's replacing existing alt text) |
| 15:45 | <webben> | ah no it's missing alt text too: "poor, incorrect, or missing ALT text" |
| 15:55 | <annevk> | should we add Ajax style stuff to http://html5.org/tools/web-apps-tracker ? as well as maybe integrating the google diff tool thingy? |
| 15:55 | <annevk> | might be interesting |
| 15:59 | <zcorpan> | bible5, lol :D |
| 15:59 | <webben> | Lachy: note that replacing missing alt text (e.g. based on the URI) is actually recommended by UAAG: http://www.w3.org/WAI/UA/UAAG10/guidelines.html#tech-missing-alt |
| 16:14 | <zcorpan> | www.whatwg.org isn't very usable with opera mini 4 beta |
| 16:16 | <annevk> | reading specs is quite a silly thing to do on a phone though :p |
| 16:16 | <zcorpan> | the home page is not a spec |
| 16:17 | <annevk> | added bible5 |
| 18:55 | <zcorpan> | use-case for style="" - plots in a map, like google maps. although perhaps <canvas> is better for that |
| 18:56 | <zcorpan> | or svg. dunno |
| 19:37 | <Dashiva> | 13 hours of no outcry over the selector naming, oh ho |
| 19:38 | <zcorpan> | Dashiva: indeed :) |
| 19:42 | Philip` | wonders if it's meant to be possible to say CanvasRenderingContext2D.prototype.fillRect = function () { ... }; canvas.getContext('2d').fillRect() and have it work |
| 19:42 | <Philip`> | (That does seem to work in Firefox and Opera, but not in Safari) |
| 19:42 | <Philip`> | (but I have no idea where such things would be specified, if anywhere) |
| 19:43 | <zcorpan> | Philip`: what, prototypes in general? |
| 19:44 | <Philip`> | I'm not sure whether it's a general one, or just specific to that case |
| 19:48 | <Philip`> | Hmm, looks like it is kind of specific to that case - I can add to HTMLCanvasElement.prototype in Safari, but the variable CanvasRenderingContext2D doesn't actually exist |
| 19:49 | <Philip`> | and getContext('2d').prototype is undefined |
| 19:52 | <Dashiva> | zcorpan: Are you installed at Opera yet? |
| 19:53 | <Lachy> | I finished writing and revising all examples, cleaned up conformance criteria and various other issues! I think Selectors API is read to be republished as a WD :-) |
| 19:54 | <Dashiva> | Wonder if selectors API will affect gEBCN in html5 |
| 19:55 | <zcorpan> | Dashiva: yeah |
| 19:55 | <Lachy> | dunno. it seems a bit redundant |
| 19:55 | <Dashiva> | zcorpan: Oslo office or somewhere in Sweden? |
| 19:55 | Lachy | wonders if anyone would bother typing getElementsByClassName() when they can type selectAllElements() so much easier |
| 19:56 | <zcorpan> | Dashiva: the latter. linköping |
| 19:56 | <zcorpan> | Lachy: depends on which is implemented first :) |
| 19:56 | zcorpan | notes that gEBCN is implemented in firefox |
| 19:56 | <Lachy> | although, gEBCN would be useful if you have a an array of classnames, selectAllElements() would be useful if you have a selector string |
| 19:57 | <zcorpan> | yeah |
| 19:57 | <Lachy> | so, it gEBCN has a small use case |
| 19:57 | <Dashiva> | I imagine gEBCN also will handle escaping when necessary |
| 19:57 | <Lachy> | escaping? |
| 19:58 | <Dashiva> | For class names bordering on symbolism |
| 20:00 | <Lachy> | Dashiva: I don't understand. Could you give an example? |
| 20:01 | <Dashiva> | Like if someone decides to make a class name containing a period |
| 20:03 | <Lachy> | oh, I see. You're confusing the escapting required in selectors due to the syntax, with a general requirement to escape such characters. They won't need to be escaped in gEBCN |
| 20:04 | <Dashiva> | Well, the result is the same, that you don't have to worry about what your class names are made up of |
| 20:05 | <Lachy> | ok |
| 20:38 | <Philip`> | Lachy: Is it intentional that the Selectors spec doesn't mention CSS in its first sentence? (I would have thought it ought to, as an effective way of immediately telling people pretty much all they need to know (except the function names) about the API, under the assumption that a reasonable number of people know what CSS selectors are) |
| 20:40 | <Lachy> | I couldn't figure out a way to fit a reference to CSS into the intro. any suggestions? |
| 20:41 | <Lachy> | there was a reference to CSS 2.1 in the intro of this revision http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.19&content-type=text/html;charset=UTF-8 |
| 20:41 | <Philip`> | Maybe "The Selectors API specification defines methods for retrieving Element nodes from the DOM by matching against a group of selectors, using the CSS Selectors syntax [Selectors]." or something? |
| 20:43 | <Lachy> | no, calling them CSS Selectors is wrong. But are you suggesting that for the abstract or intro? |
| 20:44 | <Philip`> | [Selectors] talks about CSS selectors several times |
| 20:44 | <Philip`> | I was thinking of the abstract, since that's the first bit I read and it seems like it should make it clear what 'selectors' actually are |
| 20:45 | <Lachy> | maybe something like this... |
| 20:46 | <Lachy> | "The Selectors API specification defines methods for retrieving Element nodes from the DOM by matching against a group of selectors: the selection syntax that is widely used in CSS" |
| 20:47 | <Lachy> | it needs work. I'll think about it |