Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
James said, in replying to Brian: A while ago there was a whole report about who screen readers fail with AJAX apps, then someone actually ASKED some blind folks if they could navigate the site... they managed to do so just fine. To what report and response are you referring? Do you have a link? That would probably be Joe Clark's testing of Basecamp for the Iceweb conference: http://joeclark.org/access/research/ice/iceweb2006-test-results.html To say that the results show that blind users managed just fine would be stretching the truth. The Ajax parts of the application *did* put stumbling blocks in the way of screen readers but using learned behaviour, users were able to get around the Ajax. But that's a long way from saying that Ajax is accessible. Most of the larger Ajax apps aren't accessible to screen readers to any usable degree. For the small to mid scale Ajax applications, the question of whether or not they're accessible is questionable and varies on a case by case basis. I think it's great that we're now gathering data on exactly how screen readers handle the title attribute of the abbr element but I would caution against expecting a clear "yay" or "nay" answer. Accessibility and checklists rarely make good bedfellows. Even after all the research, the final question of "is this accessible?" will still be a judgement call. There are a number of truths here are that are Kenobi-esque in nature: For the existing abbr-design-pattern, the English text "May first" is an abbreviation of the ISO date "2007-05-01"... from a certain point of view. Because a screen reader doesn't convert an ISO date in the title attribute of the abbr element into words, the abbr-design-pattern is inaccessible... from a certain point of view. And really, placing any machine-readable data in the body of an HTML document (rather than the head) is semantically questionable... from a certain point of view. So we compromise. The abbr-design-pattern was a compromise to begin with. It was a very good and clever solution but it has its limits. Those limits are now being reached (research pending). The proposed expansion, the title-design-pattern, is also a compromise. It's far from ideal but it will help to mitigate the problems that are inherent in encoding machine-readable data in markup. My point is this: the decision of how to encode this kind of data should come down to human judgement. The publisher of the data should have an option to encode datetime or geo data in a way that they feel makes most sense from a semantic point of view, a practical point of view, or a mixture of both. For example, should the title-design-pattern be adopted (and I sincerely hope it will), I will--in certain cases--still use the abbr- design-pattern to encode some machine-readable data. I think that an ISO date that doesn't include the time and uses dashes to separate its components is acceptable to present to screen readers. Others, like James, would no doubt disagree. It's a judgement call but I don't intend to stop using the abbr-design-pattern on this page, for instance: http://adactio.com/about/speaking.php But in other situations, where I want to encode complete datetimes and timezones, I really don't want to present that information to screen reader users and I would like to have the choice of encoding in an other element, even if it is slightly less semantic... from a certain point of view. My point is that even with plenty of empirical data on screen reader behaviour, and even with the rules laid down in the HTML spec, there are some situations--like this one--where the human factor needs to be given more weight. Or at least, publishers need to have the option to weigh the human/machine benefits at their own discretion. I believe that the title-design-pattern offers publishers that option while still allowing the abbr-design-pattern to be used at the discretion of the publisher. In short, sometimes the needs of the few outweigh the needs of the many*. In matters of accessibility, I don't think the 80/20 rule can or should be applied and I don't think we should any crystal clear answers to emerge from testing assistive technology (though I wholeheartedly agree that the testing should happen). Please forgive that long ramble when I could have just summarised it by saying "accessibility isn't binary": http://adactio.com/journal/1224/ Bye, Jeremy * well, I had to throw a Star Trek reference in there to balance out the Star Wars. -- Jeremy Keith a d a c t i o http://adactio.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
Brian Suda wrote: the whole discussion begs the question about what people with assistive technologies ACTUALLY think? A while ago there was a whole report about who screen readers fail with AJAX apps, then someone actually ASKED some blind folks if they could navigate the site... they managed to do so just fine. To what report and response are you referring? Do you have a link? We skirt the issue by moving data to the title attribute of alternative elements, how do we know screen-readers now or later won´t read out those as well? The article states: With custom verbosity settings, it is possible that a screen reader user may hear the text spoken in [the span]..., but that circumstance is much less likely than a fully-expanded ABBR. Screen readers allow custom verbosity settings, so it's possible that someone could enable *[title] to be read, but it is less likely than reading abbr[title] due to the implied expansion semantics of abbr. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
Brian Suda wrote: On 4/29/07, Jeremy Keith <[EMAIL PROTECTED]> wrote: If we were to find an existing HTML element that was semantically suited to encoding datetime and/or geo information *and* didn't cause problems with assistive technology, then I would jump all over it and agree wholeheartedly that the title-design-pattern should be restricted to that particular element. But I don't believe such an element exists. ... We skirt the issue by moving data to the title attribute of alternative elements, how do we know screen-readers now or later won´t read out those as well? we are coding around a problem by potentiall creating other ones and ignoring the semantics of the HTML spec in the process. > Could someone point me to the place(s) where I can read about the advantages and disadvantages of all of the possible ways of encoding data with html document tags and attributes? I realise this might not be in one place. I'd like to help in some way but I feel I'm missing the part where people discussed things like encoding data in class names (e.g. dt-20070605) or partitioning of data in title attributes (i.e. if you want to represent more than one item of data, can you put both in one attribute). Hopefully I won't suggest stupid ideas if I can fully review prior content (without having to review the whole irc/mailman archive hopefully). Many thanks Tim Parkin p.s. so far I think it would be inconsistent to arbitrarily limit the title to just span (if abbr isn't used). Obviousness is a good attribute for a 'format' to have and it's not obvious to me why a title should only appear on a certain element(s) in this case. p.p.s The examples used above are not suggestions but examples of something that I'm assuming has been discussed previously. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
On 4/29/07 8:10 AM, "Patrick H. Lauke" <[EMAIL PROTECTED]> wrote: > Brian Suda wrote: > >> We are naively ASSUMING that people with assistive technologies NEED >> our help. > > I would suggest that common sense, based on the sample of screen reader > output provided in the WaSP article, does indeed lead us to assume, but > it's an informed assumption. Better to not even require an informed assumption. Patrick, it would greatly benefit the precision and confidence in any proposal if you could help document some of the specific screen readers mentioned in the WaSP article on the microformats wiki: http://microformats.org/wiki/assistive-technology Following that, the current results that have been confirmed with using such technologies with actual microformatted content in the wild that uses abbr, perhaps on a page like: http://microformats.org/wiki/assistive-technology-abbr-results >> I would prefer, before WE think we can hand the right >> soltion down from on high, that someone who uses a screen-reader as >> their main browser give their feedback. > > Then we should build some test cases with the various proposed changes > to the abbr pattern (general title-design-pattern on a variety of > elements, a span-design-pattern, etc), and have them tested. WaSP ATF > can certainly help in this endeavour. Agreed and this would help any such proposal. However I do think we first need such documentation of the abbr results so that we can compare and see just what actual incremental advantage would result from adopting any particular proposal. >> We skirt the issue by moving data to the title attribute of >> alternative elements, how do we know screen-readers now > > Because James, Bruce and I (as well as probably a few others that hame > chimed in on the discussion) have reasonable experience of current > screen reader behaviour in the here and now. Please share your expertise with specifics: http://microformats.org/wiki/assistive-technology Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
Brian Suda wrote: We are naively ASSUMING that people with assistive technologies NEED our help. I would suggest that common sense, based on the sample of screen reader output provided in the WaSP article, does indeed lead us to assume, but it's an informed assumption. I would prefer, before WE think we can hand the right soltion down from on high, that someone who uses a screen-reader as their main browser give their feedback. Then we should build some test cases with the various proposed changes to the abbr pattern (general title-design-pattern on a variety of elements, a span-design-pattern, etc), and have them tested. WaSP ATF can certainly help in this endeavour. We skirt the issue by moving data to the title attribute of alternative elements, how do we know screen-readers now Because James, Bruce and I (as well as probably a few others that hame chimed in on the discussion) have reasonable experience of current screen reader behaviour in the here and now. or later I thought microformats was supposed to be a technology that works *today*, not some hypothetical future? As such, yes, it may or may not have to adapt with changes in the technological landscape. won´t read out those as well? we are coding around a problem by potentiall creating other ones and ignoring the semantics of the HTML spec in the process. I'd temper that with: the microformats' group *interpretation* of the HTML spec. The semantic meaning has already been slightly stretched to fit the abbr-pattern, in my (and some other members' and non-members') opinion, anyway. P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
On 4/29/07 7:44 AM, "Brian Suda" <[EMAIL PROTECTED]> wrote: > On 4/29/07, Jeremy Keith <[EMAIL PROTECTED]> wrote: >> If we were to find an existing HTML element that was semantically >> suited to encoding datetime and/or geo information *and* didn't cause >> problems with assistive technology, then I would jump all over it and >> agree wholeheartedly that the title-design-pattern should be >> restricted to that particular element. But I don't believe such an >> element exists. > > the whole discussion begs the question about what people with > assistive technologies ACTUALLY think? A while ago there was a whole > report about who screen readers fail with AJAX apps, then someone > actually ASKED some blind folks if they could navigate the site... > they managed to do so just fine. Agreed. This is definitely one of the reasons why we emphasize real world examples and data. > We are naively ASSUMING that people with assistive technologies NEED > our help. I would prefer, before WE think we can hand the right > soltion down from on high, that someone who uses a screen-reader as > their main browser give their feedback. >From talking with them at SXSW I do know that at least Derek Featherstone and James Craig have done some real world research on what ABBR does, but what we need to do now is to document their results in detail on the wiki in order to be sure that we are addressing the specific problems found, rather than potentially theoretical expansions/generalizations to problems. James, could you start with documenting the specific assistive technologies that you are testing (with version numbers, estimated # of users etc.) http://microformats.org/wiki/assistive-technology The next step would be to create a wiki page that documents tests that have been done with results, using specific assistive technologies, and URLs to specific content in the wild that uses microformats with abbr today. Perhaps something like: http://microformats.org/wiki/abbr-assistive-technology-tests > We skirt the issue by moving data to the title attribute of > alternative elements, how do we know screen-readers now or later won´t > read out those as well? We don't. And frankly, at this point, rather than take another "best guess" as I did with the abbr for datetime, and later extended to other data types (numbers, enumerated type values), any proposal should be tested as well in those same specific assistive technologies with test cases. > we are coding around a problem by potentiall > creating other ones and ignoring the semantics of the HTML spec in the > process. Agreed. Adopting a proposal like the one that has been put forth without sufficient research and documentation may not actually make the situation any better in practice (while being semantically weaker). Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
On 4/29/07 4:43 AM, "Jeremy Keith" <[EMAIL PROTECTED]> wrote: > So the problem becomes one of damage control. Certainly *any* proposal can be improved by limiting/reducing the potential damage it does. > Tantek's proposed damage limitation is to open up the abbr-design- > pattern to just one other element. With the possible examples of , or . > James and I want to open up the pattern to any element but limit the > damage by restricting the number of classes the pattern applies to. With the class names (quoting from earlier in your message) dtstart, dtend, duration, rdate, rrule (from hCalendar). type (sub property), latitude, longitude (from hCard). But I *think* what you really mean (or intended) is class names for the following microformat property types: * dates * datetimes * numerical values (e.g. coordinates) * enumerated English words which would also include for example: bday (from hCard) dtreviewed, rating, version, type (from hReview) and any other microformat properties that may be developed of those types. > But if the consensus is that Tantek's proposed damage limitation > makes the most sense, I will quite happily go along with that. This isn't an either or situation - both limitations could be applied to the title-design-pattern proposal to further minimize the damage it might do. Again, I'm not saying I agree nor support this proposal, I'm only trying to improve what is being considered. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
On 4/29/07, Jeremy Keith <[EMAIL PROTECTED]> wrote: If we were to find an existing HTML element that was semantically suited to encoding datetime and/or geo information *and* didn't cause problems with assistive technology, then I would jump all over it and agree wholeheartedly that the title-design-pattern should be restricted to that particular element. But I don't believe such an element exists. the whole discussion begs the question about what people with assistive technologies ACTUALLY think? A while ago there was a whole report about who screen readers fail with AJAX apps, then someone actually ASKED some blind folks if they could navigate the site... they managed to do so just fine. We are naively ASSUMING that people with assistive technologies NEED our help. I would prefer, before WE think we can hand the right soltion down from on high, that someone who uses a screen-reader as their main browser give their feedback. We skirt the issue by moving data to the title attribute of alternative elements, how do we know screen-readers now or later won´t read out those as well? we are coding around a problem by potentiall creating other ones and ignoring the semantics of the HTML spec in the process. -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
Tantek said: 1. Not backwards compatible with existing microformatted non-abbr elements. and Here is a simple (theoretical) example (hReview fragment) 3 Yes, but the proposal is to limit the title-design-pattern to *specific* classes As James said: Any element, but only on specific Microformat classes, each of which has expected RegEx-matchable values. DTSTART, DTEND, DURATION, RDATE, RRULE expect values defined in RFC 2445. TYPE and GEO expect values defined in RFC 2426. This would eliminate the ambiguity of title-or-contents. These kind of rules already exist in microformats. Take the url value in hCard, for example. Parsers look for the value in the href attribute, not between the tags. In that case there is a simple rule for parsers to obey. By restricting the title-design-pattern to a limited number of values, we can provide equally straightforward rules for parsers. Now... there's also the issue of multiple class names and how parsers should handle the situation with one of the classes that James lists *plus* another class. Here's an example from a (theoretical) vevent: May Day According to the proposed title-design-pattern, the value for dtstart is extracted from the title attribute while the value of summary is extracted from between the tags. dtstart: 2007-05-01 summary: May Day Limiting the title-design-pattern to specific classes like this would counter the second argument: 2. Too big of a change. In a way, what's being proposed here is an inverted version of Tantek's suggestion: If on the other hand, you were to simply extend the abbr-title pattern to *one* other element (rather than *all* non-abbr elements), then the additional damage would be less than were you to extend it to all elements. Rather than limit the title-design-pattern to one (other) element, it makes more sense to me to limit the number of scenarios where the title-design-pattern applies at all (specifically: datetime and geo information). Defining a specific element to use feels restrictive to me. We've already run into plenty of trouble with the abbr element from people, quite fairly, questioning the semantic appropriateness. For me, one of the great strengths of microformats is that they generally don't mandate what elements should be used. There's already a misconception out there that microformats "demand" the use of superfluous divs and spans (a misconception probably derived from the examples and specs and something I hope to address with some tutorials at some stage). If we introduce a design pattern that mandates the use of a specific element, I feel that might place an unnecessary burden on publishers. I realise that introducing the title-design-pattern for a limited number of classes introduces a burden for parsers but I'm okay with that. :-) Most importantly, the existing practice of encoding datetime and geo information in the title attribute of an abbr element is entirely compatible with the proposed title-design-pattern (restricted to these specific classes). To give an example of why I wouldn't want to be restricted to a specific element (and again, this is purely theoretical so take it with a huge pinch of salt), I might want to publish: May Day Rather than being forced to nest elements: May Dayspan> or: May Day Now, with all that said... If we were to find an existing HTML element that was semantically suited to encoding datetime and/or geo information *and* didn't cause problems with assistive technology, then I would jump all over it and agree wholeheartedly that the title-design-pattern should be restricted to that particular element. But I don't believe such an element exists. In the absence of such an element, I'm in favour of allowing this pattern on any element. But I'm well aware of the problem: The other point that has been made that the title attribute on HTML4 elements in general (excluding abbr, acronym) is meant for the author to provide "advisory information about the element". Semantically, we're somewhat screwed. We're damned if we use the abbr element (stretching the definition of abbreviation and causing problems for screen readers) and we're damned if we use any other element (abusing the title attribute to hold information that is not advisory information). So the problem becomes one of damage control. Tantek's proposed damage limitation is to open up the abbr-design- pattern to just one other element. James and I want to open up the pattern to any element but limit the damage by restricting the number of classes the pattern applies to. But if the consensus is that Tantek's proposed damage limitation makes the most sense, I will quite happily go along with that. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ ___ microformats-discuss mailing list microformats-discuss
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
Tantek Çelik wrote: Generalizing this overloading of the title attribute to *any* element seems like a really bad idea from the perspective of minimal change. Any element, but only on specific Microformat classes, each of which has expected RegEx-matchable values. DTSTART, DTEND, DURATION, RDATE, RRULE expect values defined in RFC 2445. TYPE and GEO expect values defined in RFC 2426. This would eliminate the ambiguity of title-or- contents. preferred casa Austin ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
Tantek Çelik wrote: And though it may seem odd that I'm simultaneously arguing against the proposed title-design-pattern and attempting to improve it, even if I am against a particular proposal, I would much rather attempt to improve it in good faith, for the benefit of having the best possible proposals be discussed, than not. This is wise, and I will follow your example: The seconds in ISO 8601 are optional, and are almost always "00"... Since screen readers sometimes pronounce HH:MM correctly but rarely get HH:MM:SS correctly, it would be better to avoid using seconds, too. Although I don't believe it's good enough, omitting the seconds would make time pronunciations slightly better, as including the dashes makes date pronunciations slightly better. "2007-04-29T12:30:00+06:00" would be "two thousand seven dash zero four dash twenty nine tee twelve thirty zero zero plus six o'clock" "2007-04-29T12:30+06:00" would be "two thousand seven dash zero four dash twenty nine tee twelve thirty plus six o'clock" Note: In negative time zones (i.e. Pacific is "-08:00"), the hyphen is usually pronounced as "dash." I am not aware of any non-custom verbosity defaults than pronounce the hyphen as "minus." Therefore, though "two o'clock plus five o'clock" makes *some* vague sense as a time zone adjustment to 7 AM, "two o'clock dash five o'clock" implies a 3-hour duration from 2 AM until 5 AM rather than the intended meaning of 9 PM the previous day. Quoting a recurrence example from the Microformats wiki at: http://microformats.org/wiki/hcalendar-brainstorming#Laughing_Squid Then we put in the quite lengthy explicit specification of every other time the event occurs, marked up around the human readable description. 20050420T1200-0700/PT4H, 20050421T1200-0700/PT7H" > Tu/Wed: 12-4pm Th/Fr/Sat 12-7pm Sun 12-6pm In Jaws 8 on Windows XP, this is pronounced, "Hey you... yeah you, 'Blindey.' F**k off." ;-) Cheers, James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
Tantek Çelik wrote: Patrick H. Lauke wrote: Forgive my newness to this, but: could you provide some examples of where the generalised title-design-pattern would be problematic? Here is a simple (theoretical) example (hReview fragment) 3 There is no ambiguity here. From the spec, the parser should understand that the integer is the machine-readable data. Quoting from the Microformats wiki entry for hReview: "rating. optional. fixed point integer [1.0-5.0], with optional alternate worst (default:1.0) and/or best (default:5.0), also fixed point integers, and explicit value." Would this noise be a problem for end users, or just for the tools that consume microformats? Neither directly. Rather, it would be a problem for the sites who have already published microformats, because we would be redefining something they are already doing. We're not suggesting that existing Microformat parsers remove their support for abbr-design-pattern. We're suggesting that Microformat authors stop using abbr-design-pattern for data not mean to be consumed by humans. I would expect that sites like Technorati and plug-ins like Operator and Tails, continue parsing abbr-design-pattern as-is to avoid breaking backwards compatibility. In otherwords, while *currently*, the use of a title attribute on non-abbr microformatted elements has *NO IMPACT* on the microformat semantics of that non-abbr element, with the title-design-pattern, those sites that were using 'title' for "advisory information" would suddenly find that that "advisory information" had been redefined to take the place of a microformat value, thus very likely breaking their microformatted content. Only if that "advisory information" matched the expected data format for that particular class. Do you know of any current implementation where this would fail? Examples "in the wild" of course. ;-) James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
On 4/28/07 8:04 PM, "Patrick H. Lauke" <[EMAIL PROTECTED]> wrote: > Tantek Çelik wrote: > >> 1. Not backwards compatible with existing microformatted non-abbr elements. > >> The problem is that there are already *non* abbr elements out there that >> contain microformatted information in the element text *and* a title >> attribute that is informational (e.g. for a tool tip). That is, they >> already have a title attribute which is *not* machine readable information, >> and if you were to *grow* the abbr-title semantic to any-element-title, then >> you would all of a sudden get a bunch of noise as tooltip text was picked up >> where the contents of the element were intended. > > Forgive my newness to this, but: could you provide some examples of > where the generalised title-design-pattern would be problematic? Here is a simple (theoretical) example (hReview fragment) 3 The author intended "rating" to be "3", not "Three means fair". > Would this noise be a problem for end users, or just for the tools that > consume microformats? Neither directly. Rather, it would be a problem for the sites who have already published microformats, because we would be redefining something they are already doing. In otherwords, while *currently*, the use of a title attribute on non-abbr microformatted elements has *NO IMPACT* on the microformat semantics of that non-abbr element, with the title-design-pattern, those sites that were using 'title' for "advisory information" would suddenly find that that "advisory information" had been redefined to take the place of a microformat value, thus very likely breaking their microformatted content. >> The other point that has been made that the title attribute on HTML4 >> elements in general (excluding abbr, acronym) is meant for the author to >> provide "advisory information about the element". >> >> http://www.w3.org/TR/html401/struct/global.html#h-7.4.3 > > We could stretch the semantic meaning of "advisory information" to cover > machine-readable data (advising the browser/tools), just the same way > that some of us believe saying that human readable dates are just an > abbreviation for machine readable ISO dates is a stretch. A different type of stretch. It stretches what is meant by "advisory", or who/what is being *advised*, rather than the fact that a precise datetime coordinate *is* very much a semantic expansion of a shorthand datetime reference which consists often of only the time, or the day, etc. >> One important (deliberately designed) aspect of the abbr-title usage is that >> it specifically limited the extent to which additional semantics were >> implied to *only* the abbr element, and thus minimized the "damage" that was >> being done to the title attribute as a whole. > > But this didn't minimize the damage to an entire group of users...those > using assistive technology. To be precise, those using assistive technology which has been documented to have a problem with reading ISO dates. That being said, I do think we need to solve this problem by solving the discrete cases (tools) as much as possible. I've created a wiki page for collecting the list of assistive technologies that are being used for testing etc. so that we can grow our understanding over time, please add to it: http://microformats.org/wiki/assistive-technology >> Generalizing this overloading of the title attribute to *any* element seems >> like a really bad idea from the perspective of minimal change. >> >> If on the other hand, you were to simply extend the abbr-title pattern to >> *one* other element (rather than *all* non-abbr elements), then the >> additional damage would be less than were you to extend it to all elements. >> >> The obvious candidate given the examples used for demonstration is . > > This sounds like a fairly good compromise to me. > >> There may be other elements that can be used for this purpose however, that >> are used less often than , and semantically meaningless (perhaps >> purely presentational - thus being fair game for semantic repurposing, like >> maybe). > > I'd argue that isn't, by its very definition, presentational: Apparently I was unclear. What I meant was there may be *other* elements that are used less often than and that are purely presentational. I wasn't saying that was presentational. > But I'm done arguing :) We're not arguing on that point :) >> I don't have a specific proposal here, other than pick one >> element rather than all, and then I think it gives the other-element-title >> pattern a better chance. > > I'd go with a span-design-pattern in replacement of the > abbr-design-pattern. That wasn't what I was proposing. I proposed going with a one-other-element(perhaps span)-title-pattern as a replacement for the title-design-pattern in these discussions. > However, does that mean the abbr-design-pattern is > to be deprecated for anything other than very restricted cases (for > dates, and then only using th
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
Tantek Çelik wrote: 1. Not backwards compatible with existing microformatted non-abbr elements. The problem is that there are already *non* abbr elements out there that contain microformatted information in the element text *and* a title attribute that is informational (e.g. for a tool tip). That is, they already have a title attribute which is *not* machine readable information, and if you were to *grow* the abbr-title semantic to any-element-title, then you would all of a sudden get a bunch of noise as tooltip text was picked up where the contents of the element were intended. Forgive my newness to this, but: could you provide some examples of where the generalised title-design-pattern would be problematic? Would this noise be a problem for end users, or just for the tools that consume microformats? And, if it's the latter, would it not be easier to fix these tools rather than expect assistive technology vendors to amend their products because of this group's interpretation of what title on an abbreviation can contain and what the AT should or shouldn't do when it encounters machine-readable data (e.g. reinterpret it back into human-readable form, or omit it completely, to protect the end user from hearing gibberish)? The other point that has been made that the title attribute on HTML4 elements in general (excluding abbr, acronym) is meant for the author to provide "advisory information about the element". http://www.w3.org/TR/html401/struct/global.html#h-7.4.3 We could stretch the semantic meaning of "advisory information" to cover machine-readable data (advising the browser/tools), just the same way that some of us believe saying that human readable dates are just an abbreviation for machine readable ISO dates is a stretch. One important (deliberately designed) aspect of the abbr-title usage is that it specifically limited the extent to which additional semantics were implied to *only* the abbr element, and thus minimized the "damage" that was being done to the title attribute as a whole. But this didn't minimize the damage to an entire group of users...those using assistive technology. Generalizing this overloading of the title attribute to *any* element seems like a really bad idea from the perspective of minimal change. If on the other hand, you were to simply extend the abbr-title pattern to *one* other element (rather than *all* non-abbr elements), then the additional damage would be less than were you to extend it to all elements. The obvious candidate given the examples used for demonstration is . This sounds like a fairly good compromise to me. There may be other elements that can be used for this purpose however, that are used less often than , and semantically meaningless (perhaps purely presentational - thus being fair game for semantic repurposing, like maybe). I'd argue that isn't, by its very definition, presentational: "The DIV and SPAN elements, in conjunction with the id and class attributes, offer a *generic mechanism for adding structure to documents*." http://www.w3.org/TR/html401/struct/global.html#h-7.5.4 Also, the fact that no browser gives them any default presentation would seem to support this. But I'm done arguing :) I don't have a specific proposal here, other than pick one element rather than all, and then I think it gives the other-element-title pattern a better chance. I'd go with a span-design-pattern in replacement of the abbr-design-pattern. However, does that mean the abbr-design-pattern is to be deprecated for anything other than very restricted cases (for dates, and then only using the format with dashes and colons that, at a stretch, is at least slightly less offensive when read out to end users)? And if so, is that not "too big a change", as it would effectively break all uses in the wild which up to now have relied on the abbr-design-pattern? Don't get me wrong, I'm not still flying the flag for a general title pattern, just wondering if this won't tick off all early adopters of microformats (particularly if tools such as Operator are modified not to support abbr in favour of span, and/or to flag it as an error if abbr is used for anything other than the restricted use scenario)? P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ ___ microformats-discuss mailing list microformats-di
Apology for duplicate (was [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change)
On 4/28/07 7:22 PM, "Tantek Çelik" <[EMAIL PROTECTED]> wrote: > I don't have a specific proposal here, other than pick one > element rather than all, and then I think it gives the other-element-title > pattern a better chance. > > Tantek Apologies for the incomplete duplicate that got sent prematurely. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
Jeremy, While certainly I am swayed by many of your well reasoned arguments, I must point out one particular flaw: 1. Not backwards compatible with existing microformatted non-abbr elements. On 4/28/07 2:12 PM, "Jeremy Keith" <[EMAIL PROTECTED]> wrote: > I'd also like to point out one of the beauties of the proposed title- > design-pattern: it's completely backwards compatible with the abbr- > design-pattern. The abbr-design-pattern uses the title attribute of a > *specific* element: the title-design-pattern uses the title attribute > of *any* element. This is not entirely correct. Being backward compatible with microformatted abbr elements is only *part* of the backward compatibility problem. There other part is being backward compatible with existing microformatted non-abbr elements, which is where the problem is. The problem is that there are already *non* abbr elements out there that contain microformatted information in the element text *and* a title attribute that is informational (e.g. for a tool tip). That is, they already have a title attribute which is *not* machine readable information, and if you were to *grow* the abbr-title semantic to any-element-title, then you would all of a sudden get a bunch of noise as tooltip text was picked up where the contents of the element were intended. I've seen these in numerous examples in the wild, and if there is dispute on the existence thereof, can document as necessary. 2. Too big of a change. As illustrated by the backward compatibility case above, this may be too big of a change. The other point that has been made that the title attribute on HTML4 elements in general (excluding abbr, acronym) is meant for the author to provide "advisory information about the element". http://www.w3.org/TR/html401/struct/global.html#h-7.4.3 One important (deliberately designed) aspect of the abbr-title usage is that it specifically limited the extent to which additional semantics were implied to *only* the abbr element, and thus minimized the "damage" that was being done to the title attribute as a whole. Even then I hesitated before proposing it, and only after exhausting what I thought were perhaps other workable alternatives (e.g. object, and yes, Safari's marketshare was significant enough to cause Yahoo to pull object-include-pattern support, so others made that distinction as well). Generalizing this overloading of the title attribute to *any* element seems like a really bad idea from the perspective of minimal change. If on the other hand, you were to simply extend the abbr-title pattern to *one* other element (rather than *all* non-abbr elements), then the additional damage would be less than were you to extend it to all elements. The obvious candidate given the examples used for demonstration is . There may be other elements that can be used for this purpose however, that are used less often than , and semantically meaningless (perhaps purely presentational - thus being fair game for semantic repurposing, like maybe). I don't have a specific proposal here, other than pick one element rather than all, and then I think it gives the other-element-title pattern a better chance. And though it may seem odd that I'm simultaneously arguing against the proposed title-design-pattern and attempting to improve it, even if I am against a particular proposal, I would much rather attempt to improve it in good faith, for the benefit of having the best possible proposals be discussed, than not. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
Jeremy, While certainly I am swayed by many of your well reasoned arguments, I must point out one particular flaw: 1. Not backwards compatible with existing microformatted non-abbr elements. On 4/28/07 2:12 PM, "Jeremy Keith" <[EMAIL PROTECTED]> wrote: > I'd also like to point out one of the beauties of the proposed title- > design-pattern: it's completely backwards compatible with the abbr- > design-pattern. The abbr-design-pattern uses the title attribute of a > *specific* element: the title-design-pattern uses the title attribute > of *any* element. This is not entirely correct. Being backward compatible with microformatted abbr elements is only *part* of the backward compatibility problem. There other part is being backward compatible with existing microformatted non-abbr elements, which is where the problem is. The problem is that there are already *non* abbr elements out there that contain microformatted information in the element text *and* a title attribute that is informational (e.g. for a tool tip). That is, they already have a title attribute which is *not* machine readable information, and if you were to *grow* the abbr-title semantic to any-element-title, then you would all of a sudden get a bunch of noise as tooltip text was picked up where the contents of the element were intended. I've seen these in numerous examples in the wild, and if there is dispute on the existence thereof, can document as necessary. 2. Too big of a change. As illustrated by the backward compatibility case above, this may be too big of a change. The other point that has been made that the title attribute on HTML4 elements in general (excluding abbr, acronym) is meant for the author to provide "advisory information about the element". http://www.w3.org/TR/html401/struct/global.html#h-7.4.3 One important (deliberately designed) aspect of the abbr-title usage is that it specifically limited the extent to which additional semantics were implied to *only* the abbr element, and thus minimized the "damage" that was being done to the title attribute as a whole. Even then I hesitated before proposing it, and only after exhausting what I thought were perhaps other workable alternatives (e.g. object, and yes, Safari's marketshare was significant enough to cause Yahoo to pull object-include-pattern support, so others made that distinction as well). Generalizing this overloading of the title attribute to *any* element seems like a really bad idea from the perspective of minimal change. If on the other hand, you were to simply extend the abbr-title pattern to *one* other element (rather than *all* non-abbr elements), then the additional damage would be less than were you to extend it to all elements. The obvious candidate given the examples used for demonstration is . There may be other elements that can be used for this purpose however, that are used less often than , and semantically meaningless (perhaps purely presentational - thus being fair game for semantic repurposing, like maybe). I don't have a specific proposal here, other than pick one element rather than all, and then I think it gives the other-element-title pattern a better chance. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
