Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
Andy Mabbett wrote: Tantek Çelik writes the blog post on hAccessibility WaSP was seriously flawed [...] 2. It recommended known unworkable solutions Perhaps you missed this part: We encourage the Microformats group to consider the problem, whether or not they accept any of the following, proposed solutions. There is one other part Tantek may have missed when he wrote: In addition I think this is a case where a little bit of pain now with abbr and some tools actually opens up the potential for *much* better accessibility/usability tools (once UAs actually recognize ISO dates as such and can speak/rewrite them for a user's datetime/language/locality preferences). I for one think this tradeoff is more than reasonable. The article also states: The Microformats group is vehemently opposed to hypothetical situations as the basis for a Microformat change. Real-world examples are often requested, or as they commonly phrase it, examples “in the wild.” We remind the Microformats group that real-world screen reader implementations existed, according to spec and “in the wild,” long before the Microformats design patterns, and we encourage the group to respect those real-world implementations, rather than focusing on hypothetical situations... The screen readers may support ISO dates someday argument is a great idea–I will laud it if it happens–but it's completely hypothetical. Surely you can admit that, and if so, maybe you can admit the argument is not a legitmate justification for the datetime- design-pattern, and especially not for the use of abbr-design-pattern in geo. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
Jeremy Keith wrote: James Craig wrote: Due to opening up the pattern a bit more, there will also need to be a flag to indicate when to use title attribute versus contents. Something like this useTitle class: No, this smells like a really bad idea. That class is now an instruction for machines. Fair enough. Retracted. I would however recommend limiting the very specific classes so that it's not abused to hide data other than specifically machine readable info like the ISO dates and Geo coords. For the record, I believe the machine-readable RFC type vales (home, work, cell, fax, etc.) also fall into this category, mainly for the sake of i18n. The spec now forces them to be visible, yet it does not make sense to force English words to be visible on pages in other languages. Hence the example: abbr class=type title=home xml:lang=esCasa/abbr James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
Tantek Çelik wrote: To be frank - the blog post on hAccessibility WaSP was seriously flawed. 1. It used a strawman example to argue against. What about our example was a straw man? Just yesterday it was mentioned that Yahoo uses dates without dashes and wikevent was given as an example of using the slightly better dates with dashes. Let's use wikevent's in the wild example (that includes timezones) and talk about what happens with the date portion of this ISO string: 2007-05-07T20:00:00+01:00. I don't have Jaws in front of me, but the time is either going to be read as twenty o'clock zero zero plus one o'clock or as twenty zero zero zero zero plus one o'clock. Both are nearly useless to human ears. 2. It recommended known unworkable solutions (using object? are you kidding me? that's already been tried and failed - did you not do your homework? see my original abbr post, and include-pattern-feedback). In addition I told James Craig *in person* about this at SXSW, so I was a bit surprised it still made it to the blog post. As Andy pointed out, the point of the article was not the proposed solutions, but I want to point out that your reason for being hung up on the object example is because it was tried and failed due to UA implementation bugs. The argument you're making here completely contradicts the argument you make later in this same email here (quoted, but out of order): OTOH, not allowing bugs and stubbornness of implementers to retard/ slow/stop progress and nor taking a step backward and using span instead. [...] However, I'm against contorting microformats because of bugs or suboptimal behaviors in 1% marketshare browsers. I don't really consider screen readers as browsers. People who use 1% market share browsers have a choice to change or upgrade. The people who use screen readers really have no other way to access online content. Yes, they could turn off the title attribute verbosity, but this would then cause ambiguity of understanding other, valid uses of abbr. I doubt you would agree with the following statement: I'm against contorting building code regulations to require wheelchairs ramps and elevators in public buildings because of the 1% of citizens with mobility impairments. So I'm for adding - and : to get a better and even *usable* result in screen readers, I agree with you that the date portion (-mm-dd) with dashes, though sub-optimal, is better. I told you this in our discussion at SXSW. I also immediately mentioned that's only the case with dates, not datetimes. The complete ISO timecode is gibberish with or without punctuation; I completely deny your claim that it's usable. I think there needs to be a balance. I agree. I know we all have the specifications' best interests in mind, and I'm glad it's finally in full discussion. 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) span class=rating title=Three means fair3/span 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] changing abbr-design-pattern to title-design-pattern?
Absalom Media wrote: Although in all my testing on this issue, the date-time-pattern still announced the date correct (at least for hAtom, with dashes and colons) in terms of screenreader testing (JAWS 8 at advanced verbosity, Window Eyes 6 and Firevox). I'm still somewhat confused as to why I've got different results than the ones reported on the WASP post by Jon Gibbons. http://dotjay.co.uk/tests/screen-readers/date-time/#test-microformats Any ideas? Or should I raise this with WaSP? Please do either here, on the WaSP comments, or both. We'd love to know your test results and how they differed. 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: 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. abbr class=rdate title=20050407T1200-0700/PT7H, 20050408T1200-0700/PT7H, 20050409T1200-0700/PT7H, 20050410T1200-0700/PT6H, 20050412T1200-0700/PT4H, 20050413T1200-0700/PT4H, 200504014T1200-0700/PT7H, 20050415T1200-0700/PT7H, 20050416T1200-0700/PT7H, 20050417T1200-0700/PT6H, 20050419T1200-0700/PT4H, 20050420T1200-0700/PT4H, 20050421T1200-0700/PT7H Tu/Wed: 12-4pm Th/Fr/Sat 12-7pm Sun 12-6pm /abbr 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] changing abbr-design-pattern to title-design-pattern?
Jeremy Keith wrote: Microformats have always been a here-and-now technology rather than a utopian idea for some future Semantic Web (see: RDF and other noble but failed W3C technologies). LOL. Poor RDF. There is an RDF thread about the article going on here: http://burningbird.net/semanticweb/accessibility-microformats-and-rdf- as-the-bezoar-stone/ It could have been worse. It could have been RDF. I'd be interested in hearing if anyone else feels as strongly as I do that the title-design-pattern is something that should codified as soon as possible. +1, but you knew that already. ;-) 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: 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. span class=type title=foopref/spanerred em class=type title=homecasa/em li class=geo title=30.300474;-97.747247Austin/li ___ 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) span class=rating title=Three means fair3/span 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: span class=dtstart summary title=2007-05-01May Day/span 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: h1 class=dtstart summary title=2007-05-01May Day/h1 Rather than being forced to nest elements: h1 class=summaryspan class=dtstart title=2007-05-01May Day/ span/h1 or: h1span class=dtstart title=2007-05-01span class=summaryMay Day/span/span/h1 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
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
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 span, or b. 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
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 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] changing abbr-design-pattern to title-design-pattern?
On 4/28/07, Jeremy Keith [EMAIL PROTECTED] wrote: I'd be interested in hearing if anyone else feels as strongly as I do that the title-design-pattern is something that should codified as soon as possible. I'd be even more interested in hearing if there's anybody, like Tantek, who feels that it's a bad idea... or to be more accurate, who feels that the practical benefits don't outweigh the semantic purity. Can we start a Wikipage, with the alternatives/variants and listing their advantages disadvantages? If there isn't a pressing crisis: measure thrice, cut once. Also would be a better place to record votes than e-mails. Regards, etc... David -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] abbr debate and Accessify
In message [EMAIL PROTECTED], Brian Suda [EMAIL PROTECTED] writes 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. as I wrote, over 24 hours ago: In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes I would also suggest raising the matter on forums used by blind (and other) people who use text readers - Accessify being one such forum: http://www.accessifyforum.com/ Note also that this issue was discussed previously, both there and on Accessify, in September 2006: http://microformats.org/discuss/mail/microformats-discuss/2006-September/005667.html http://www.accessifyforum.com/viewtopic.php?t=6167 I'd urge everyone participating now, to read that debate. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.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
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] changing abbr-design-pattern to title-design-pattern?
Le 29 avr. 2007 à 02:53, Tantek Çelik a écrit : However, I'm against contorting microformats because of bugs or suboptimal behaviors in 1% marketshare browsers. Reading loudly the content of title attribute is *not* a bug or suboptimal behavior for a vocal browser. That would be equivalent to say that it is a bug to display the title content in visual browser as just plain text. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] changing abbr-design-pattern to title-design-pattern?
Tantek Çelik wrote: However, I'm against contorting microformats because of bugs or suboptimal behaviors in 1% marketshare browsers. On my reading of the HTML 4.01 specification and WCAG 1.0, the title attribute was clearly intended to provide additional /human readable/ information: http://www.w3.org/TR/html401/struct/global.html#adef-title http://www.w3.org/TR/html401/struct/text.html#edef-ABBR http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-abbr On this reading, the use of title for information formatted for machines not people is a hack. So I think it's erroneous to describe reading out the ISO date time format from title as a bug. I agree having a setting to recast ISO dates into a localized, human readable format might be an optimal behaviour, but it would be best if such conversion was triggered only in contexts where the ISO format was not meant for direct human consumption. In this sense, describing it as suboptimal behaviour presumes screen reader foreknowledge of microformats, which seems to go against the already quoted credo of the microformats movement. Your interpretation of the relevant specs may be different, of course. :) With regards to the attempt to list screen readers on the microformats wiki, I'd like to draw correspondents attention to the list of past and present screen readers on Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_screen_readers The current microformats wikipage's emphasis on the latest versions is somewhat misplaced. It's important to remember that partly because popular screen reading software is prohibitively expensive, many screen reader users are using older versions. I'm subscribed to several screen reader mailing lists. The latest version of Freedom Scientific's JAWS (probably the most popular screen reader) is 8. But judging from mailing lists dedicated to JAWS and other screen readers, users of 8 are outnumbered by users of 7. Many correspondents are still on 6. Some few correspondents still use 5 or even 4.51, e.g.: http://www.freelists.org/archives/jfw/03-2007/msg00857.html http://www.freelists.org/archives/jaws-uk/03-2007/msg00125.html With web browsers, one might have a moral case for putting the onus on users to upgrade to free and technically superior alternatives, though taking such a moral position appears not to be a widely viable commercial practice. But in the case of screen readers, the free solutions still have a long way to go to be very effective replacements for their expensive peers, so a similar moral argument is difficult to construct. I'm afraid asking for estimates of the size of the userbase for each version is a bit unrealistic. There's very little public information about such matters. The World Health Organization estimated that in 2002, 37 million people around the world (0.59%) were blind and an additional 124 million (1.99%) had low vision: http://www.who.int/gb/ebwha/pdf_files/WHA59/A59_12-en.pdf 3.58% is only a little short of estimates of Safari's market share and much higher than estimates of Opera's: http://marketshare.hitslink.com/report.aspx?qprid=0 Of course, because people with visual impairments are likely to have poorer life opportunities and to be older, I'd guess they are under-represented in uptake of new technologies and the internet generally. In 2002, Chris Hofstader of Freedom Scientific testified that There are approximately 80,000 registered users of JAWS: http://web.archive.org/web/20021015235548/http://www.microsoft.com/presspass/trial/mswitness/2002/hofstader.asp I assume he meant worldwide, but it's hard to be certain. According to a study of screen reader use published in December 2003, a spokesperson for the US National Federation of the Blind estimated that in the USA, JAWS had 65% of the screen reader market and GW-Micro Window-Eyes had 35%; also JAWS was the software most commonly used by U.S. federal workers: http://www.redish.net/content/papers/interactions.html If these figures held true beyond the US, one could predict around 40,000 registered Window-Eyes users worldwide. However, non-US markets may favour other screen readers such as the Brazilian screen reader MicroPower Virtual Vision. In a published interview with Access World in March 2007 that proved controversial and has subsequently disappeared from the site, Hofstader apparently said that 2,000 copies of screen reader software are sold per month: http://blogs.sun.com/korn/date/20070309 Any sale of a Mac is also a sale of VoiceOver, an effective screen reader. Any download of Ubuntu Linux or Solaris is also a download of Orca, an increasingly competent open source screen reader. With regards to the particular issue at hand, it's fortunate that many screen reader users probably have not configured their software to read title automatically since: 1) It's not the default behaviour in JAWS or Window-Eyes. 2) Current screen readers do not (AFAIK) discriminate between familiar and unfamiliar,
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] changing abbr-design-pattern to title-design-pattern?
Welcome to microformats-discuss Benjamin! On 4/29/07 3:14 PM, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: Tantek Çelik wrote: However, I'm against contorting microformats because of bugs or suboptimal behaviors in 1% marketshare browsers. On my reading of the HTML 4.01 specification and WCAG 1.0, the title attribute was clearly intended to provide additional /human readable/ information: http://www.w3.org/TR/html401/struct/global.html#adef-title http://www.w3.org/TR/html401/struct/text.html#edef-ABBR http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-abbr Agreed. On this reading, the use of title for information formatted for machines not people is a hack. Certainly formatted for machines and *unreadable* to people would be yes, e.g. a datetime in pure binary, or even just an integer such as seconds since 1970-01-01T00:00Z. ISO8601 dates (and datetimes) are actually quite readable for many people (e.g. it might have taken you a second or two, but I'm sure you were able to parse the previous sentenc) even though they are clearly intended to be easier for machines to read. The point is that human readability and machine readability are not necessarily in opposition/conflict. Often you can get *both*. Sometimes (as with ISO dates) you get something that is mostly or at least somewhat human readable, just so that it *can be* machine readable. One of the microformats principles is humans first, machine second. That doesn't mean machines *never*. It means that microformats *do* still aim to make machine readable formats. So I think it's erroneous to describe reading out the ISO date time format from title as a bug. Depends on the reading. Even words *could* be misread/mispronounced. I agree having a setting to recast ISO dates into a localized, human readable format might be an optimal behaviour, but it would be best if such conversion was triggered only in contexts where the ISO format was not meant for direct human consumption. In this sense, describing it as suboptimal behaviour presumes screen reader foreknowledge of microformats, which seems to go against the already quoted credo of the microformats movement. Just because microformats are designed to work today, that doesn't mean they are restricted to those solutions where *all* behaviors are expected to work today. Microformats work today very simply and immediately for *some* uses, perhaps only even *one* use today. However, by expressing semantics, they are specifically designed to enable and encourage *new* and more intelligent uses. The works today is a minimal bar to be met, not a restriction. Your interpretation of the relevant specs may be different, of course. :) With regards to the attempt to list screen readers on the microformats wiki, I'd like to draw correspondents attention to the list of past and present screen readers on Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_screen_readers Thanks very much for providing this reference. It points out that our goal should NOT be to simply duplicate the work done elsewhere with a comprhensive list of assistive technologies (including screen readers). Rather, since the goal is real world testing of actual microformats content in the wild, we restrict the technologies on that list to those which those in the community have access to, or are in direct communication with someone who has access to. I've noted this on the wiki page so that we can stay focused on actionable research: http://microformats.org/wiki/assistive-technology The current microformats wikipage's emphasis on the latest versions is somewhat misplaced. I just re-read the page and apologize for whatever I wrote that gave that impression. To be clear, I think the key focus here is (quoted from the top of the page) currently known accessibility assistive technologies (implementations) that are being used in the wild In other words, obsolete implementations that are not being used are not worth documenting for our purposes (or certainly doing so should be the lowest priority). It's important to remember that partly because popular screen reading software is prohibitively expensive, many screen reader users are using older versions. I'm subscribed to several screen reader mailing lists. The latest version of Freedom Scientific's JAWS (probably the most popular screen reader) is 8. But judging from mailing lists dedicated to JAWS and other screen readers, users of 8 are outnumbered by users of 7. Many correspondents are still on 6. Some few correspondents still use 5 or even 4.51, e.g.: http://www.freelists.org/archives/jfw/03-2007/msg00857.html http://www.freelists.org/archives/jaws-uk/03-2007/msg00125.html Thanks for that information. I have added those specific versions of JAWS to the wiki: http://microformats.org/wiki/assistive-technology#JAWS If you have additional information such as rough numbers of users, or dates of when those
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
Tantek Çelik wrote: Certainly formatted for machines and *unreadable* to people would be yes, e.g. a datetime in pure binary, or even just an integer such as seconds since 1970-01-01T00:00Z. ISO8601 dates (and datetimes) are actually quite readable for many people (e.g. it might have taken you a second or two, but I'm sure you were able to parse the previous sentenc) even though they are clearly intended to be easier for machines to read. The point is that human readability and machine readability are not necessarily in opposition/conflict. Often you can get *both*. I may interject here that there is potentially a distinction to be made between readability and hearability. If assistive technology such as screen readers doesn't know what a certain piece of text/numbers is, it will (and yes, we're organising thorough testing and documentation among WaSP ATF members as we speak) read it out character by character, digit by digit. Imagine if the text of this email was read out to you, not as words, but letter by letter...how much more difficult would it be for you to then understand it? Sure, it's certainly not impossible (you just need to keep mental track of all the characters being read out to you, then mentally form them into words again), but certainly far from ideal in the here and now. The works today is a minimal bar to be met, not a restriction. So then that bar isn't met for screen reader users for the case presented in the WaSP article. In other words, obsolete implementations that are not being used are not worth documenting for our purposes (or certainly doing so should be the lowest priority). Agree completely. But not entirely impossible nor unreasonable. The reality is that software *does* get improved over time. Just the fact that JAWS is up to version 8 demonstrates this, and demonstrates sufficient demand for new versions JAWS that the publishers keep updating it. Therefore there is a case to be made for both encouraging improvements (since history has shown that software does get improved), and clearly there is demand for better software (sufficient to support the market), for encouraging the consumers of such software to demand even better software. However (pending the testing results), in the context of screen readers and the abbr pattern this would be exactly like saying we're going to use object, even though we know safari doesn't play ball with it...as once we demonstrate sufficient demand etc etc safari team will be compelled to update their software. 2) Current screen readers do not (AFAIK) discriminate between familiar and unfamiliar, or even first-occurrence and repeated, abbreviations and acronyms when reading title attributes. Please indicate which specific screen readers and versions you know that about on the wiki page. No screen reader does this sort of thing, to my knowledge. Again, we'll try to get some testing done (geez, this is turning into a testing marathon...I understand this whole burden of proof thing is on us, but still...) 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
[uf-discuss] Re: Best practice for the abbr pattern
Both upcoming and eventful do not have dashes in their dates. They will need to be evangelized. I'll fix Eventful's hCalendaring to reflect this some time this week. Ted -- Edward O'Connor [EMAIL PROTECTED] Ense petit placidam sub libertate quietem. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
