Revisiting the choice of <abbr> for unAPI?

[Barry.McMullin]

Hi Folks -

I'm coming very cold to the discussion here, and am only reading
my way into unAPI; so apologies in advance if I commit gross
blunders!

I was initially very surprised to see the <abbr> pattern being
used as it is in unAPI. I have now reviewed the original (?)
discussion of this choice here:

<http://old.onebiglibrary.net/yale/cipolo/gcs-pcs-list/2006-May/
000855.html>

As far as I can see, in that discussion, there was no mention
of the conflict between the <abbr> pattern and web accessibility
for users with disability (for whom the correct, semantic, use of
<abbr> is potentially very important).

I note that, at one stage in the original discussion above, this
source was referenced:

<http://microformats.org/wiki/abbr-design-pattern>

Visiting that source *now*, there is a clear highlighting of the
accessibility issue. However, briefly tracking back through the
edit history, I'm believe that this was not present at the time
of the unAPI discussion. In any case, I want to argue that this
is *not* a small or trivial issue. See the detailed discussion
here:

<http://www.webstandards.org/2007/04/27/haccessibility/>

So, my question is twofold:

- Have I missed some more recent unAPI-specific discussion where
this problem has already been addressed?

- If not, I would like to suggest revisiting the original
adoption of <abbr>. I recognise that it might be very
painful to try to unpick this now; but, as things stand, it
*seems* to me that the
current spec could be a show stopper for at least
some applications (but please correct me if I am
mistaken).

Best - Barry.

[Alf Eaton]

Hi Barry,

I think the conclusion was to go with whatever the microformats community decided. If abbr goes out of fashion there (which seems unlikely) then unAPI (if it was ever to be updated) would probably follow suit.

alf

[Barry McMullin]

On Wed, 7 Nov 2007, Alf Eaton wrote:

> I think the conclusion was to go with whatever the microformats
> community decided. If abbr goes out of fashion there (which
> seems unlikely) then unAPI (if it was ever to be updated) would
> probably follow suit.

Hi Alf -

Thanks for that. It does make sense, but it is rather
unfortunate. I will dig a little deeper into what the up-to-date
situation is with the generic microformats community.

Note that nobody is objecting to using ABBR for a microformat,
when the usage is consistent with ABBR semantics and
accessibility requirements. So not all microformat usage of ABBR
is deprecated. But, in the specific case of unAPI, the usage is,
in fact,, contrary to ABBR semantics, and can, furthermore, be
expected to directly cause real world problems for accessibility.

In the meantime, unfortunately, I won't be able to make any usage
of unAPI myself, or, indeed, recommend it to anyone else; and I
can't really believe I will be unique in that ...

Best wishes,

- Barry.

--
Barry McMullin, Dublin City University
phone: +353-1-700-5432
web: http://www.eeng.dcu.ie/~mcmullin/

[Jonathan M. Lane]

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.

[Dan Chudnov]

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

[Jonathan M. Lane]

Hi Dan,

On Mon, Apr 4, 2011 at 01:29, Dan Chudnov <dc...@umich.edu> 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
value-class-pattern microformat?

Jonathan

[Mike Rylander]

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 ...

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

[Mike Rylander]

On Tue, Apr 5, 2011 at 2:36 PM, Galen Charlton <gmch...@gmail.com> wrote:
> Hi,

>
> On Tue, Apr 5, 2011 at 2:26 PM, Mike Rylander <mryl...@gmail.com> 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]

On Tue, Apr 5, 2011 at 4:21 PM, Galen Charlton <gmch...@gmail.com> wrote:
> Hi,
>

> On Tue, Apr 5, 2011 at 3:49 PM, Mike Rylander <mryl...@gmail.com> 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.

[schuyler]

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 @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 @itemprop and/or @itemtype
values to indicate an unapi-id

cheers,
Schuyler Duveen
Senior Programmer
Columbia Center for New Media Teaching and Learning
s...@columbia.edu

On Apr 5, 5:17 pm, Mike Rylander <mrylan...@gmail.com> wrote:

> On Tue, Apr 5, 2011 at 4:21 PM, Galen Charlton <gmcha...@gmail.com> wrote:
> > Hi,
>

[Galen Charlton]

Hi,

On Tue, Apr 5, 2011 at 3:49 PM, Mike Rylander <mryl...@gmail.com> 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
gmch...@gmail.com

[Galen Charlton]

Hi,

On Tue, Apr 5, 2011 at 2:26 PM, Mike Rylander <mryl...@gmail.com> 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 Charlton]

Hi,

On Wed, Apr 6, 2011 at 3:42 PM, schuyler <schuy...@gmail.com> wrote:
> First, to solve the accessibility issue clinically, perhaps we can
> just recommend adding attribute @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?

[schuyler]

On Apr 7, 9:26 am, Galen Charlton <gmcha...@gmail.com> wrote:
> Hi,
>

> On Wed, Apr 6, 2011 at 3:42 PM, schuyler <schuyle...@gmail.com> wrote:
> > First, to solve the accessibility issue clinically, perhaps we can
> > just recommend adding attribute @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.