- From: John Foliot <jfoliot@stanford.edu>
- Date: Mon, 6 Nov 2006 09:45:33 -0800
- To: "'Lachlan Hunt'" <lachlan.hunt@lachy.id.au>
- Cc: <Chaals@opera.com>, <w3c-wai-ig@w3.org>
Moved to the W3C WAI-Interest list only (per requests), with a one-time separate notification sent out to WebAIM and WHATWG lists for those who may not follow wai-ig. Cheers! JF ************ Lachlan Hunt wrote: > > That sounds like bureaucratic, political nonsense. I can't understand > why any organisation would let a little, meaningless cross on some > form get in the way of real-world, practical accessibility benefits. > It makes me glad that HTML 5 dispenses with useless DTD based > validity. LOL - hey, I don't disagree, although it is a real world bureaucratic requirement. But at it's base there is some validity: If you are going to have and use standards, then have and use standards, and use them in a standard way. Else don't have standards and do things in a non-standard way... But be prepared to suffer the consequences. I don't think a pedantic approach is always the right way, but there is an equal argument to be made for being "proper". > You're better off > finding a > RelaxNG schema, adding the role attribute to it and claiming > "validity" against that (just so you can tick the box on the form and > keep the bureaucrats happy :-)). ...and Lachlan, if that is what it takes, then sure, give 'er. But as any scientist will tell you, you need to have a benchmark or standard to measure up against, and if a DTD is not the place, then where and how would you propose? I can see the scientist/bean-counter perspective too, whether at some levels it is "nonsense" or not. > > Can you send me a link to the implementation and test cases for it? > If that can demonstrate real practical benefits along with an existing > implementation, that could strengthen the case for including role in > HTML5. > Test cases: http://www.cita.uiuc.edu/software/mozilla/test/ts-test-page-role.php Toolbar download: http://cita.rehab.uiuc.edu/software/mozilla/ > > Only because the <a> element is a better alternative for links, given > that <link> is not useful to the vast majority of users without > something like a link toolbar in their browser. However, from an > implementation perspective as far as keyboard binding are concerned, > those links should work just as well as the equivalent <a> links. > >> More importantly, they exist in the specs today, they are just poorly >> used >> (if ever), and have minimum support from the browser makers. > > Exactly! Poor use and lack of support is a very good reasons to drop > a feature. Given that HTML4 has been around 8 years, if those > features aren't supported yet, there's little hope they will be. While I would be hard pressed to disagree, I suspect that part of the problem with their current non-use is both a lack of understanding and awareness, as well as a failure of WYSIWYG tools to provide access to these most useful elements. Sadly, we've also been cobbled with a negative chicken and egg scenario, where, because they weren't being used, browser support for them became less critical (especially during the first browser wars, where <marquee> and <blink> fought it out, and on-screen flashy was naively the rage and focus of browser development). Developer awareness of Semantic Web structure, standards, and on-line accessibility issues have matured to the point where I suspect that a bit of an overhaul and re-introduction of the relative link could see a resurgence of these elements. (I like to believe so) There may be times when linking to a concept container ("policies"?) may not be directly achievable (or desirable) via the anchor element; this would be the perfect case for the relative link with an @role declaration. I would caution not to toss the baby out with the bathwater. > >> However, I think what is more important than the rel/role debate is >> the concept of a 'standardized' list beyond that which exists today >> for the relative link, which is essentially what you are alluding to >> here. A listing of intent (similar to what has emerged for >> microformats) is what is needed, but the mechanism(s) to "use" that >> intent should be left to the >> user-agent(s) > > Yes, that's exactly right! New link types are planned to be included > in HTML5. I don't know for sure, but it will probably include those > that have gone through the microformats process, which have already > proven to be useful. To include any new link type in HTML5 (or > anything else for that matter), we'd need solid use cases, evidence > to back up whether or not authors would actually use it and a good > description of the benefits it provides to users. Well, at this time, this may be hard to "prove". I have engaged many, many people on the subject of accesskeys, and the overwhelming consensus is that a means of providing accelerator keyboard shortcuts for interpage navigation is not only desirable, but in some cases truly needed. I've never argued that point, and totally agree with that assertion. The problem has always been the way accesskey is/was implemented, which has lead to poor uptake by developers, and poor adoption by end users. The current problems are pretty well documented (and I could assemble a more cohesive collection of them if so required), but we need to now come up with a better way. So adding a new method requires something of a leap of faith, and needs to be better thought out than what we currently have. > > Well, I'm sure you would agree, that having a useful mechanism to find > help for filling out form controls is good for both accessibility and > usability. In this example, we already have <label> to associate some > content with a specific form control and we have rel="help" to > indicate > a link to get help, merging the concepts seems quite logical. It's > basically the same way some microformats work, by building new > semantics from a combination of existing semantics. In that context, yes, that makes sense. > >>> *The Role Attribute* >> >> Well... There are mechanics and then there are results. From a >> pragmatic perspective, I really don't see much of a difference >> between >> rel and role as you have outlined it. I think the bigger issue is >> that a standardized list of "intent characters" (again, think >> microformats) is required, [...] > > Yes, I agree. The way we need to do it is to identify the use cases > and then try to meet those use cases with what we've already got. If > what > we have is clearly inadequate for the use case, then we can look at > introducing something new. Hmmm... There is inadequate and then there is logical/practical. Since we've referenced microformats already, I can look there as a possible use-case. While I understand why microformats have chosen "class" as the identifier of choice, I think honestly that it is a "make-do" solution rather than a structured and reasoned solution. One overarching concern I have is that as we move forward, everything is going to be dumped into <div>s with classes and IDs, and that good old-fashioned semantic HTML (lowercase s) will give way to this "classed" style markup, which would have I believe practical negative effects for accessibility. I think that @role would actually benefit microformats; which makes more sense - <p role="vevent"></p> or <p class="vevent"></p>? (<p role="vevent" class="weekday"></p>, <p role="vevent" class="weekend"></p> - ?!?) > >> E) @role currently suggests the ability to define custom roles (RDF) >> - this may in fact be very useful - although again how it would be >> consumed by user-agents is not yet 100% clear (and is, I believe, the >> crux of Chaal's argument for the ability to "hint" a keybinding - but >> again, I won't speak for him) > > If you're correct, it sounds to me like Chaal's argument is > effectively that "RDF doesn't solve our problem, so we need to give a > keybinding as well". If that's true, that indicates that they need > to rethink their solution, rather than patch a broken one. I'd also > like to add that RDF is a complex language for the average author and > it's highly unlikely to see any significant use for this in the real > world. > Well, again, I can hardly speak for Chaals (who is quite eloquent in his own right), but I don't think that is exactly what he is saying. The overall concept of @role (as I understand it in terms of "accessibility") is that we now have a means to identify content blocks and other key fragments within a document, so that they can be accessed quickly using non-traditional means (keyboard shortcuts, but possibly others). Part of that work is/was the creation of a common collection of roles - a standard list, again similar to the class assertions of microformats. For the majority of web-developers out there, implementation and "standardization" of this common collection would suffice 99.99% of the time - so long as we get the common collection right [action item]. @role also allows (in specialized circumstances) for the creation of custom roles. For these roles to be effective, they need to be defined (and RDF is good for that) - yes, RDF is "tricky", but if the common collection is robust enough, the need for custom roles would be rare, and if you can create a need for a custom role, then you should be able to define it well enough to use RDF to do so. Chaals suggests (if I understand him correctly) that for user agents, some method of "hinting" a keybinding (in a vacuum) would be a good thing, although I would counter that if a browser could discover a custom role, why would it need to discover a keybinding, and not just instead announce the presence of the custom role and allow the author to set their own key? However, I am hardly a browser developer, so I do not know or appreciate the technical challenge this may present. Remember as well, that this is all in the context of my concern over @key in XHTML 2. >> I personally like the idea of role as it more closely defines what we >> are >> talking about, <snip> > Absolutely agree! I'm not against role in any way, it just needs to > be proven useful. <snip> > If the only reason it's getting implemented is that it's "new" and > "edgy", then that would seem like a good indication of being useless. > So I hope that's not the case. <snip> > ...microformats seem to be bringing new life into link relationships. > Just look at XFN, rel-tag and (sadly) rel-nofollow. It's interesting > that after only a few months, rel="nofollow" became the 6th most > frequently used link relationship! Well, taken out of context, but in order, I think you've kinda made my point. A 'new kid on the block' (microformats = "new & edgy") breathes life into a forgotten bit of old-school HTML - the relative link. A year (18 months?) ago the argument for abandoning the relative link (or at least good chunks of it) would have been quite strong... But then along comes XFN and it's need/use of the relative link and all of a sudden it's a whole different ball-game; as you stated, now link-relationships are being re-thought and implemented - sometimes in ways not originally conceived when the spec was created. At this time we are hard-pressed to "prove" the usefulness of @role, because we do not have a means to implement or use the concept. Unlike the machine consumable microformats, @role suggests a way to improve user-interaction, but again, it's a chicken and egg scenario - we have no mainstream tools today that adequately expose and avail itself to the benefit (Prof. Gunderson's toolbar aside). It would be sad that the only reason something as useful as @role (and it's potential) did not get taken seriously is because everyone is sitting around waiting for the other guy to blink. At some point there *does* need to be some leadership - it can't all be reactionary (IMHO). JF
Received on Monday, 6 November 2006 17:46:01 UTC