Re: [uf-discuss] Hidden metadata no microformats
Benjamin West wrote: http://tantek.com/log/2005/06.html#d03t2359 Principles of visibility and human friendliness. One question invisible metadata raises is if it's not worth seeing, why is it worth publishing? Because tools/extensions expose them to end users in a way that is far more user/human friendly than merely making the raw metadata visible. Whether or not authors forget to update the metadata, or purposely try to game it, if it's not visible is an authoring/policy issue, not a technical issue that should be solved by a language's specification (because some bad people tried to do bad things with it, we're just not giving you the opportunity, full stop). 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] abbr and accessibility - a work around.
Quoting Michael MD [EMAIL PROTECTED]: Why? Unless you are a geography geek there is not that much sense in it. Geo becomes useful by conversion to something human understandable, like a map or a named location. For print you could just override the style in the print stylesheet. I can't see any harm in displaying it people might want to copy/paste it into some kind of mapping application, or compare it with output from a GPS device, etc There's a lot of things a technically-minded users may *want* to do with that sort data. I would posit, though, that the average user (who, incidentally, also doesn't really like to read things like -MM-DDThh:mm:ss.sTZD) doesn't, and is far better served with functional buttons/links or Operator-like tools. 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] abbr and accessibility - a work around.
Quoting Andy Mabbett [EMAIL PROTECTED]: You can doubt all you like, but the evidence is still there ;-) Flickr and Wikipedia are two prominent examples. Tellingly, Flickr hides that stuff by default. Wikipedia, being user generated, isn't always a beacon of best practice for usability and good web design, I'd say... -- 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] abbr and accessibility - a work around.
Andy Mabbett wrote: On the page I cited, the coordinates are in plain text, in the tags, as stated. Do you have javascript disabled? In that case, yes the geo:lat and geo:long appear there in plain text by default. Otherwise, normal users never see them unless they bother to hit the Show machine tags link...and rightly so, as people who are not into code geekery, geocaching, or some other niche pursuit that will require them access to the actual raw lat/long data, will more likely want to see something like the map display. 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] weird page problems?
Is it just me, or is there some strange spam under the Template part of http://microformats.org/wiki/abbr-design-pattern-issues ? Can't seem to see it in the edit view to remove it either. Also, http://microformats.org/wiki/accessibility-issues seems to be a completely blank page. 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] RFC: sHTML Video Thumbnailing
Charles Iliya Krempeaux wrote: a rev=thumbnail href=http://example.com/video; img src=http://example.com/thumbnail.jpg; /a I'm not sure if the rev attribute is being used correctly in your markup. Rev defines the reverse link to the current document, not to whatever is encapsulated by the link itself...unless I'm reading the spec wrong This attribute describes the relationship from the current document to the anchor specified by the href attribute http://www.w3.org/TR/html401/struct/links.html#edef-A So, the above would mean the current document as a whole is the thumbnail for http://example.com/video; rather than the img is the thumbnail for So yes, it's a slight misuse (or a case of stretching the semantics, if you will) of rev, I'd say. 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] W3HTML WG, HTML5, semantics, and so on
Ryan King wrote: I'm not sure it's clear that we need a general mechanism. AFAIK, the only real problem is with datetime fields. Everything else seems to work pretty well now. Geo information is also problematic. For example, should HTML 5 define a uf-data='' attribute as a common attribute such that the value of this attribute would be considered in preference over textContent by microformat consumers? Or should HTML 5 just mitigate the damage to the title attribute by defining a boolean attribute title-is-uf='' for flagging title='' attributes not meant for human consumption? I don't think so. This fails to solve a specific problem (solves a general problem that I'm not sure we need to solve). It also encourages hiding data, which is Not a Good Thing(tm). How would that encourage more hiding data than the current use of title? 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] a[name] as machine data?
Toby Inkster wrote: Better than a[name] would be a[href], assuming a relevent URI scheme exists: a href=geo:51.36,-0.05London, abbr title=United KingomUK/abbr/a (See: http://geouri.org/) Disadvantages would be: 1. Involves using a poorly supported URI scheme. People using browsers that don't support the scheme would get a link that doesn't do anything, or brings up a cryptic message. (This could be worked around with a combination of CSS and Javascript, but that seems a bit hackish to me.) 2. This requires there to always *be* such a URI scheme. There isn't a URI scheme for timestamps for instance. URI schemes cannot be quickly and easily registered. 3. This puts those links in the tab cycle for keyboard users, and on a page listing lots of events it would turn into tabbing hell. 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] In-the-wild datetimes for screenreader testing
Andy Mabbett wrote: I would be foolish in the extreme for anyone to dismiss your results on those grounds. ...they'll just label them as strawman examples... 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] Regarding POSH and misuse of the microformats logo
Frances Berriman wrote: This is kind of why I have a problem with the POSH thing. Yeah, it's meant to be a bit of a joke (and plenty of people are laughing) - but for those people that would actually benefit from improving their knowledge of HTML and semantics - seeing another acronym with unknown origins thrown around isn't necessarily going to make them learn any more! Also, from a marketing perspective, I'd posit that plain and old are probably not the best terms to sex up and sell the idea. 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] human readable date parsing
Scott Reynen wrote: I'd invite you to document the list of every possible way to represent each month in plain text, and then let us know if you still think reading through such a list to figure out how to publish dates is easier for publishers. Maybe I've lost track of the original issue here, but: publishers don't need to know all variations in all languages, just the version in the language they're authoring, no? 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] human readable date parsing
Tantek Çelik wrote: To be clear, this clause, in the absolute, is undesirable. That is, in following the principles of microformats, the date needs to be at least somewhat *visible* to humans, rather than invisible. But not the machine-readable part, if it makes no sense to the human reader. 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] Expanding the abbr pattern
Ben Wiley Sittler wrote: in some cases you can get away with not using abbr: Q1 '07: span class=dtstart2007-01-01/span through span class=dtend2007-04-01/span with hyphens it's reasonably human-readable. i've been using fully punctuated iso 8601 date notation it everyday life (checks, contracts, even announcements) for years with no problems whatsoever. Just want to raise, at this point, the problem an author might face with regards to an organisation's house styles. For instance, at my university, we have very specific guidelines for how dates and times etc should be written (hint: it ain't ISO-anything). 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] Expanding the abbr pattern
Ben Wiley Sittler wrote: However, using 8601 in an abbr title and your house style in the abbr content should work just fine, right? Yes, of course. Just wanted to add the concept that, as authors, sometimes the content part of pages isn't fully up to us either :) 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] human readable date parsing
Tantek Çelik wrote: 2. Keep both copies of the data at least somewhat visible to humans so that at least *some* human eyes/ears can easily inspect both copies and ensure that they have not diverged. For the sake of argument, though: assuming that those human eyes/ears use a microformat-consuming tool/extension/etc, this can still happen. If I have a page with, say, contact details marked as a hcard, and human users export it to Outlook, they'll be able to see (and ensure) whether or not the generated vcard details in the add to address book dialog match the page's visible details or not. After all, isn't that what microformats are there for? Being consumed by machines that can make something useful with them? 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] human readable date parsing
Al Gilman wrote: If the machineable info is not routinely passing through the consciousness of the communicating principals (that is, people), Who may, without the machine-mediated interpretation, not actually be able to make a qualitative judgement (e.g. if I see a geo lat/long value , I'm not enough of a walking map to instantly be able to review that data...so I will need to run it through something like google maps to work out if the data is duff or not)... If in some community of communication, the data is routinely extracted into view often enough so that bad data tend to get weeded out, then the storage or transmission form doesn't have to be directly comprehensible by people. But one of the virtues of markup languages is just how much of the info is directly under the quality control of people; expressed in as little-encoded form as can be gotten away with. But to bring it back to the original argument, the routine extraction does not necessarily have to equate to data visible in, say, a tooltip. The routine extraction may well be mediated via some machine interpretation. 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] human readable date parsing
Paul Wilkins wrote:
What if the value class was to be used with a hidden class. Then they
would serve their purpose, they wouldn't interfere with existing styles
and could be interpreted correctly.
.hidden {display: hidden}
Then the human-readable and machine-readable can be mashed together. If
the screen-reading software honor hidden styles this could be the right
path to take.
That would still render the machine-readable part in the clear on
platforms with incomplete or missing support for CSS, such as some
current mobile devices. Also, it feels conceptually wrong to have
machine-readable stuff sprinkled into what should just be content.
Note that, based on current practice adopted by screen readers, only
TITLE on ABBR is explicitly being given status as human-readable.
The content of the ABBR and ACRONYM elements specifies the abbreviated
expression itself, as it would normally appear in running text. The
title attribute of these elements may be used to provide the full or
expanded form of the expression.
http://www.w3.org/TR/html401/struct/text.html#edef-ABBR
So, although the spec tempers this with a may, it does suggest this
kind of use by screen readers.
Values of the title attribute may be rendered by user agents in a
variety of ways. [...] For example, setting the attribute on a link
allows user agents (visual and non-visual) to tell users about the
nature of the linked resource:
http://www.w3.org/TR/html401/struct/global.html#adef-title
There's a may here as well, but the generic definition for title
(which could then be used on something like a span) seems far more lax
to me, and in that respect more suited to be plied/bent for microformat
data use. IMHO, of course.
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] hyperlink include-pattern - keyboard issue
I edited the page on the wiki, but thought I'd bring it up here as well http://microformats.org/wiki/include-pattern-feedback#Hyperlink_Include_-_issues_for_keyboard_users_.28including_Screen_Reader_users.29 Although invisible in visual user agents, and (according to the JAWS 7.0 test below) not spoken by screen readers (at least not by JAWS 7.0), empty links are still contained in the normal tab cycle. Users navigating via keyboard (or equivalent, e.g. switch access, puff/blow devices, etc) will still need to tab through the empty links (tested in Firefox 2.0, IE 6, IE 7; Opera 9.2 seems to remove empty links from tab cycle). This can be verified by modifying the test page below, adding a regular link at the end of the 5 variations of empty links. It takes a user 6 tabs to arrive at the real link. It would therefore be advisable to rethink the approach, or scrap it completely. 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] hyperlink include-pattern - keyboard issue
Andy Mabbett wrote: Nobody was suggesting scrapping anything for reasons of fear or cost (leastways, not financial cost - there may certainly be said to be a practical cost to people using assistive technologies). Not even limited to assistive technology. This affects all users without screen reader who just happen to use a keyboard (or equivalent), rather than a mouse, for navigation, in some of the major current browsers. 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] changing abbr-design-pattern to title-design-pattern?
Jeremy Keith wrote: I don't want to get anyone's hopes up but there's an interesting comment from Lawrence Meckan on the WaSP blog post: http://www.webstandards.org/2007/04/27/haccessibility/#comment-57838 He's getting good results from up-to-date screen readers with advance verbosity settings and this little caveat about the markup: I’ve also expanded the abbr pattern to include a span inside it, essentially duplicating the semantic structure, in order to do a fix for IE6 not styling abbrevations. If there's a chance that adding an extra span inside the abbr element somehow helps screen readers, then that should probably be included in the test cases: http://microformats.org/wiki/assistive-technology-abbr-results Like I said, we shouldn't get our hopes but it's certainly worth investigating. Just spoke quickly to Jon Gibbins on the phone, and he mentioned that it appears to be more of a bug in JAWS due to the use of sIFR (which causes JAWS to sometimes read titles, and sometimes not)...but he'll be testing this further to come to some hard evidence on that. 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
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] 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
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
Tantek Çelik 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. So you don't see the fact that *NO* current UA (particularly screen readers) recognises ISO dates and turns them into fluffy human readable output as a problem? And you're saying that you'd rather knowingly inflict a little bit of pain on end users in a move to force UA vendors to change their behaviour to ease that pain? Or am I misreading that part? 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] changing abbr-design-pattern to title-design-pattern?
Andy Mabbett wrote: For the benefit of new list members, the IRC logs are at: http://rbach.priv.at/Microformats-IRC/ The discussion referred to begins at: http://rbach.priv.at/Microformats-IRC/2007-04-27#T154600 Cheers Andy. I'm sorry, but this comment is revealing tantek OTOH, not allowing bugs and stubbornness of implementers to retard/slow/stop progress. Basically this is a complaint that current screen readers aren't yet frantically in the process of fixing their 800+ US$ software (some of which doesn't even support web standards in most cases, i.e. ignores many accessibility hooks and benefits built right into (X)HTML itself, opting for flaky heuristics instead) to support this fringe group's interpretation of what an ABBR is, and what the TITLE attribute stands for? Forgive me, but this smacks just a bit of arrogance... 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] changing abbr-design-pattern to title-design-pattern?
Jeremy Keith wrote: However, I'm against contorting microformats because of bugs or suboptimal behaviors in 1% marketshare browsers. Normally I would agree with you here. But the situation with screen readers is somewhat different. We're not talking about a regular browser here: if someone is using a sub-optimal or outdated web browser and they don't get the full benefits, then that's something that can be brushed over but for a blind person using the most up-to-date technology available to have to put up with an illegible piece of data isn't acceptable. In this particular case, the market share numbers are--to my mind--irrelevant. Also, it strikes me as interesting that the epiphany of using ABBR for storing both human and ISO dates came about mainly because of the fact that the original OBJECT has such poor support in Safari. Where was the I won't let their laziness/stubbornness stand in the way of progress attitude back then? Simply marketshare, I guess... 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. That was indeed the idea behind generalising it, yes. 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 raise my hand, but you guessed that already, didn't you? 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
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 span. 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 span, and semantically meaningless (perhaps purely presentational - thus being fair game for semantic repurposing, like b maybe). I'd argue that span 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
