Re: [WSG] Microformats Accessibility
A timely blog post by Andy...and this marks the third anniversary of the same issues being rehashed http://forabeautifulweb.com/blog/about/designing_around_haccessibility/ though Ben Ward's efforts are to be noted...see http://forabeautifulweb.com/blog/about/designing_around_haccessibility/#r356 I guess I should make sure my parser handles those... ...btw looking at the examples draws attention to a big usability problem with so-called human dates... (which has little to do with microformats or markup .. its more a problem with culture and education) If something like February 9th appears on a page is that really human-friendly? . what year is that? is it coming up ? ... or am I looking at an old page about something from last year? ... Do you really want to hide a machine date when that may the only thing on the page you can use to tell what the date actually is? It would certainly be nice if people were to learn to write human dates more clearly! Lets ban those yearless dates, dd/mm/ and mm/dd/ sillyness and anything with two digit years! *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
On 20/1/09 08:31, Michael MD wrote: If something like February 9th appears on a page is that really human-friendly? . what year is that? is it coming up ? ... or am I looking at an old page about something from last year? ... Um... depends, look at the surrounding text in this test case: http://microformats.org/wiki/value-excerption-value-title-test#hCard.231:_An_hCard_bday it's a birthday, so last year, this year, and every year thereafter. ;) It would certainly be nice if people were to learn to write human dates more clearly! I agree with this general point, though the way to write dates most clearly in English is 9 February 2009 (or, somewhat worse, February 9th 2009) not any machine-readable readable syntax. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
On Tue, Jan 20, 2009 at 8:31 AM, Michael MD md...@spraci.com wrote: ...btw looking at the examples draws attention to a big usability problem with so-called human dates... (which has little to do with microformats or markup .. its more a problem with culture and education) If something like February 9th appears on a page is that really human-friendly? . what year is that? is it coming up ? ... or am I looking at an old page about something from last year? ... Ah yes, the we know screenreader users are having problems with full ISO...but *actually* they're better because they're more unambiguous argument. Strangely, humans have been using human-friendly date/time formats since...forever, and have coped fine with ambiguity for the most part. Human communications are by their very nature fuzzy and ambiguous, and usually this fuzziness is then clarified through additional knowledge (is this blog from the US or from the UK?, when you say 'dinner at 8' i assume you mean 8PM/20:00?, etc). Yes, in a completely ideal world, if microformats weren't creating actual problems to certain users as in this case, I too would jump on the we're disambiguating the web, one datetime at a time bandwagon. But for the time being, while there are known problems, I'd rather wait until the uf community makes a concerted effort to take all the proposed alternatives that can solve the issue into consideration and adopt the best-of-breed one. Do you really want to hide a machine date when that may the only thing on the page you can use to tell what the date actually is? Ok, in both cases, the onus is on the authors of those pages and how ambiguous they are in the content creation. You bemoan the fact that authors haven't made it clear what date/time they actually mean, but then expect the same authors to also put unambiguous full ISO datetime microformats around their fuzzy information? The real solution here is to get these content authors to actually write their information in a clearer way (in clear text), I would suggest. It would certainly be nice if people were to learn to write human dates more clearly! Lets ban those yearless dates, dd/mm/ and mm/dd/ sillyness and anything with two digit years! Absolutely! Sorry, just seen that we're actually saying the same thing here, so nice one. 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 __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
I think it's a clash between microformats VS html AND accessibility standards. On Mon, January 19, 2009 12:48 am, Ben Rowe wrote: on microformats.org, it suggests the ABBR element and title attribute for machine code. however, title attribute for this element will be read out to a screen reader user. we are considering having an output of span class=namehuman valuespan class=value title=machine value/span/span however its an empty span. this method of empty spans is also suggested on microformats.org to combat accessibility issues, but wanted your suggestions / thoughts? Obviously it is a clash of HTML standards VS accessibility. I've chosen the span option because I think accessibility is more important. Ben *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
Patrick H. Lauke wrote: As the lord of microformats Tantek seems so vehemently opposed to it, I sincerely doubt it will happen any time soon. It's now been roughly three years since the debate around ABBR issues first started, and little visible progress seems to have been made. Who knows, maybe the cynic in me will be pleasantly surprised, but I won't hold my breath... A timely blog post by Andy...and this marks the third anniversary of the same issues being rehashed http://forabeautifulweb.com/blog/about/designing_around_haccessibility/ though Ben Ward's efforts are to be noted...see http://forabeautifulweb.com/blog/about/designing_around_haccessibility/#r356 -- 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/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] Microformats Accessibility
on microformats.org, it suggests the ABBR element and title attribute for machine code. however, title attribute for this element will be read out to a screen reader user. we are considering having an output of span class=namehuman valuespan class=value title=machine value/span/span however its an empty span. this method of empty spans is also suggested on microformats.org to combat accessibility issues, but wanted your suggestions / thoughts? Obviously it is a clash of HTML standards VS accessibility. I've chosen the span option because I think accessibility is more important. Ben *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
Ben Rowe wrote: Obviously it is a clash of HTML standards VS accessibility. Actually, it's a clash of microformats' misappropriation of HTML standards VS accessibility... An empty span won't kill anybody though. What you lose in code purity you gain in a slightly more accessible solution (as long as tools that consume those microformats actually recognise the span solution...been a while since I checked if that's the case - otherwise, it's purely academic). 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/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
Hey Ben, Just a note... for now the following should be used instead: span class="name"human valuespan class="value"machine value/span/span The span class="value" title="machine value"/span is still in brainstorming so should not be used yet. Reference: http://microformats.org/wiki/value-excerption-pattern-brainstorming#parsing_title_from_empty_value_elements Cheers, Anthony. Patrick H. Lauke wrote: Ben Rowe wrote: Obviously it is a clash of HTML standards VS accessibility. Actually, it's a clash of microformats' misappropriation of HTML standards VS accessibility... An empty span won't kill anybody though. What you lose in code purity you gain in a slightly more accessible solution (as long as tools that consume those microformats actually recognise the span solution...been a while since I checked if that's the case - otherwise, it's purely academic). P ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***
Re: [WSG] Microformats Accessibility
Anthony Ziebell wrote: Just a note... for now the following should be used instead: /span class=namehuman valuespan class=valuemachine value/span/span/ And rely on CSS to display:none that nested span? -- 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/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
Yes, until the brainstorm is approved and made standard. Hopefully soon, to remove the requirement of extra CSS. You could apply a span.value style, or alternatively add 'hidden' as an extra class style and apply it to that. span.value style would probably be sufficient. Regards, Anthony. Patrick H. Lauke wrote: Anthony Ziebell wrote: Just a note... for now the following should be used instead: /span class="name"human valuespan class="value"machine value/span/span/ And rely on CSS to display:none that nested span? ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***
Re: [WSG] Microformats Accessibility
Anthony Ziebell wrote: Yes, until the brainstorm is approved and made standard. Hopefully soon, As the lord of microformats Tantek seems so vehemently opposed to it, I sincerely doubt it will happen any time soon. It's now been roughly three years since the debate around ABBR issues first started, and little visible progress seems to have been made. Who knows, maybe the cynic in me will be pleasantly surprised, but I won't hold my breath... 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/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
Yes, well thankfully there is a workaround. The ABBR element and title with machine code is a serious problem so far as accessibility is concerned. Regards, Anthony. Patrick H. Lauke wrote: Anthony Ziebell wrote: Yes, until the brainstorm is approved and made standard. Hopefully soon, As the lord of microformats Tantek seems so vehemently opposed to it, I sincerely doubt it will happen any time soon. It's now been roughly three years since the debate around ABBR issues first started, and little visible progress seems to have been made. Who knows, maybe the cynic in me will be pleasantly surprised, but I won't hold my breath... P ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***
