Dan Chudnov | 4 Apr 2011 06:29
Picon

Re: Revisiting the choice of <abbr> for unAPI?

On Mar 21, 2011, at 12:38 PM, Jonathan M. Lane wrote:

> I think it might be time to revise unAPI to encourage (preferably mandate, but that's probably
unrealistic) the use of the value class pattern, which is a proven microformat pattern that does not have
the same accessibility issues as the ABBR design pattern.

Thanks for bringing this up.  Sorry for the delayed response.

I haven't been tuned in to microformats in a while.  Is this the pattern you're referring to?

  http://microformats.org/wiki/value-class-pattern

I'm not sure there's a lot to gain from updating unAPI at this point.  Are you using it?

  -Dan

--

-- 
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en.

Jonathan M. Lane | 5 Apr 2011 19:46
Picon
Gravatar

Re: Revisiting the choice of <abbr> for unAPI?

Hi Dan,

On Mon, Apr 4, 2011 at 01:29, Dan Chudnov <dchud@...> wrote:
> On Mar 21, 2011, at 12:38 PM, Jonathan M. Lane wrote:
>
>> I think it might be time to revise unAPI to encourage (preferably mandate, but that's probably
unrealistic) the use of the value class pattern, which is a proven microformat pattern that does not have
the same accessibility issues as the ABBR design pattern.
>
> Thanks for bringing this up.  Sorry for the delayed response.
>
> I haven't been tuned in to microformats in a while.  Is this the pattern you're referring to?
>
>  http://microformats.org/wiki/value-class-pattern

Exactly right.

> I'm not sure there's a lot to gain from updating unAPI at this point.  Are you using it?

I am not using it myself, but I work closely with the technical
library at my institutional library, who are actively maintaining some
unAPI access points on some of their services and systems.

While unAPI may be past it's prime (I am not certain if unAPI has been
replaced by something newer/more appealing), updating the standard to
recommend the use of a more accessibility-friendly and semantically
correct microformat would be beneficial for anyone still using unAPI
or those considering implementing it.

Any reasons why it may not be worth updating the standard to use the
(Continue reading)

Mike Rylander | 5 Apr 2011 20:26
Picon

Re: Revisiting the choice of <abbr> for unAPI?

On Tue, Apr 5, 2011 at 1:46 PM, Jonathan M. Lane <jmlane@...> wrote:
> Hi Dan,
>
> On Mon, Apr 4, 2011 at 01:29, Dan Chudnov <dchud@...> wrote:
>> On Mar 21, 2011, at 12:38 PM, Jonathan M. Lane wrote:
>>
>>> I think it might be time to revise unAPI to encourage (preferably mandate, but that's probably
unrealistic) the use of the value class pattern, which is a proven microformat pattern that does not have
the same accessibility issues as the ABBR design pattern.
>>
>> Thanks for bringing this up.  Sorry for the delayed response.
>>
>> I haven't been tuned in to microformats in a while.  Is this the pattern you're referring to?
>>
>>  http://microformats.org/wiki/value-class-pattern
>
> Exactly right.
>
>> I'm not sure there's a lot to gain from updating unAPI at this point.  Are you using it?
>
> I am not using it myself, but I work closely with the technical
> library at my institutional library, who are actively maintaining some
> unAPI access points on some of their services and systems.
>
> While unAPI may be past it's prime (I am not certain if unAPI has been
> replaced by something newer/more appealing), updating the standard to
> recommend the use of a more accessibility-friendly and semantically
> correct microformat would be beneficial for anyone still using unAPI
> or those considering implementing it.
>
(Continue reading)

Mike Rylander | 5 Apr 2011 21:49
Picon

Re: Revisiting the choice of <abbr> for unAPI?

On Tue, Apr 5, 2011 at 2:36 PM, Galen Charlton <gmcharlt@...> wrote:
> Hi,
>
> On Tue, Apr 5, 2011 at 2:26 PM, Mike Rylander <mrylander@...> wrote:
>> Evergreen (http://evergreen-ils.org/) uses unAPI extensively, so we
>> wouldn't want to see the abbr-title pattern removed, but I don't see
>> any reason to avoid aligning the spec with the value-class pattern a
>> bit in terms of supported implementation.
>>
>> Note, though, that the value for unAPI is a tag: URI, not human-usable
>> data, so it may be less applicable to unAPI than, say, hCard.  My
>> $0.02 ...
>
> It looks like that the value-title variant [1] of the value-class
> pattern would give us a way to avoid the accessibility problem while
> not inflicting opaque strings meant for machine processing on humans.
>
> [1] http://microformats.org/wiki/value-class-pattern#Parsing_value_from_a_title_attribute
>

But, isn't that exactly what unAPI specifies today in an <abbr>?

--

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker@...
 | web:  http://www.esilibrary.com

(Continue reading)

Mike Rylander | 5 Apr 2011 23:17
Picon

Re: Revisiting the choice of <abbr> for unAPI?

On Tue, Apr 5, 2011 at 4:21 PM, Galen Charlton <gmcharlt@...> wrote:
> Hi,
>
> On Tue, Apr 5, 2011 at 3:49 PM, Mike Rylander <mrylander@...> wrote:
>> But, isn't that exactly what unAPI specifies today in an <abbr>?
>
> The difference is that <abbr> has particular semantics that are used
> by screen readers; in particular, the contents of the title attribute
> are read out by screen readers.  The value-title pattern uses empty
> spans that are, according to the link, are hidden both from visual
> display and screen readers.
>

That's the point I missed.  Thanks.  Supporting both, for backward
compat, would not bother me at all.  I suspect that many unAPI
consumers actually just look for any element with a class of
'unapi-id' anyway.

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker@...
 | web:  http://www.esilibrary.com

--

-- 
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe <at> googlegroups.com.
(Continue reading)

schuyler | 6 Apr 2011 21:42
Picon

Re: Revisiting the choice of <abbr> for unAPI?

MediaThread (http://ccnmtl.columbia.edu/mediathread) searches for
unAPI information in its bookmarklet, parsing it on sites like WGBH's
OpenVault (e.g. http://openvault.wgbh.org/catalog/org.wgbh.mla:MLA001106).

The more ways we have to search for an unAPI id, the more burdensome
the spec becomes.  The ABBR element is nice because it's rare on a
page (unlike SPANs).

First, to solve the accessibility issue clinically, perhaps we can
just recommend adding attribute  <at> aria-hidden="true"
http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden

<abbr class="unapi-id" aria-hidden="true" title="abc-news-videosource:
9468a"></abbr>

If we're going to add new ways to reference unAPI IDs in HTML, I'd
suggest linking it up with the HTML5 MicroData work which solves any
accessibility issues and will have javascript apis and new tooling
connected to it.
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata

The new way would be something like:

<span itemscope itemprop="unapi-id" itemtype="http://unapi.info/unapi-
id" itemid="abc-news-videosource:9468a"></span>

with DIV and other item properties unconnected to the spec.  In this
case, the key thing is to standardize the  <at> itemprop and/or  <at> itemtype
values to indicate an unapi-id

(Continue reading)

Galen Charlton | 5 Apr 2011 22:21
Picon
Gravatar

Re: Revisiting the choice of <abbr> for unAPI?

Hi,

On Tue, Apr 5, 2011 at 3:49 PM, Mike Rylander <mrylander@...> wrote:
> But, isn't that exactly what unAPI specifies today in an <abbr>?

The difference is that <abbr> has particular semantics that are used
by screen readers; in particular, the contents of the title attribute
are read out by screen readers.  The value-title pattern uses empty
spans that are, according to the link, are hidden both from visual
display and screen readers.

Regards,

Galen
-- 
Galen Charlton
gmcharlt@...

--

-- 
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en.

Galen Charlton | 5 Apr 2011 20:36
Picon
Gravatar

Re: Revisiting the choice of <abbr> for unAPI?

Hi,

On Tue, Apr 5, 2011 at 2:26 PM, Mike Rylander <mrylander@...> wrote:
> Evergreen (http://evergreen-ils.org/) uses unAPI extensively, so we
> wouldn't want to see the abbr-title pattern removed, but I don't see
> any reason to avoid aligning the spec with the value-class pattern a
> bit in terms of supported implementation.
>
> Note, though, that the value for unAPI is a tag: URI, not human-usable
> data, so it may be less applicable to unAPI than, say, hCard.  My
> $0.02 ...

It looks like that the value-title variant [1] of the value-class
pattern would give us a way to avoid the accessibility problem while
not inflicting opaque strings meant for machine processing on humans.

[1] http://microformats.org/wiki/value-class-pattern#Parsing_value_from_a_title_attribute

Regards,

Galen
-- 
Galen Charlton
gmcharlt@...

--

-- 
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en.
(Continue reading)

Galen Charlton | 7 Apr 2011 15:26
Picon
Gravatar

Re: Re: Revisiting the choice of <abbr> for unAPI?

Hi,

On Wed, Apr 6, 2011 at 3:42 PM, schuyler <schuyler1d@...> wrote:
> First, to solve the accessibility issue clinically, perhaps we can
> just recommend adding attribute  <at> aria-hidden="true"
> http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden
>
> <abbr class="unapi-id" aria-hidden="true" title="abc-news-videosource:
> 9468a"></abbr>

Interesting, and would certainly be trivial to implement.  Since
WAI-ARIA only recently became a candidate recommendation, do you know
if enough assistive technology recognizes aria-hidden to make a
practical difference at the moment?

Regards,

Galen
-- 
Galen Charlton
gmcharlt@...

--

-- 
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en.

schuyler | 7 Apr 2011 17:12
Picon

Re: Revisiting the choice of <abbr> for unAPI?

On Apr 7, 9:26 am, Galen Charlton <gmcha...@...> wrote:
> Hi,
>
> On Wed, Apr 6, 2011 at 3:42 PM, schuyler <schuyle...@...> wrote:
> > First, to solve the accessibility issue clinically, perhaps we can
> > just recommend adding attribute  <at> aria-hidden="true"
> >http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden
>
> > <abbr class="unapi-id" aria-hidden="true" title="abc-news-videosource:
> > 9468a"></abbr>
>
> Interesting, and would certainly be trivial to implement.  Since
> WAI-ARIA only recently became a candidate recommendation, do you know
> if enough assistive technology recognizes aria-hidden to make a
> practical difference at the moment?
>
I don't have experience myself, but WAIARIA seems to be pretty widely
supported (at least partially):
http://www.iheni.com/screen-reader-testing/

Though as I'm reading more, it seems most modern screen readers ignore
things that are display:none anyway, so if anything, it's overkill.

--

-- 
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en.

(Continue reading)


Gmane