E-mail List Archives
Thread: usage of abbreviation tag
Number of posts in this thread: 12 (In chronological order)
From: Ken Petri
Date: Mon, Sep 16 2013 3:42PM
Subject: usage of abbreviation tag
No previous message | Next message →
I've been doing some screen reader experiments on use of the abbr /
abbreviation tag. At this point, I've only worked with JAWS and NVDA in IE
and Firefox (latest versions, Windows 8) but it's been frustrating so far.
Here's what I'm hearing:
Nothing at all in NVDA, regardless of what I do.
Expansion in JAWS, only after I turn on "expand abbreviations" in
preferences.
I could find no way in either screen reader to easily determine if an
abbreviation has an expansion.
One reason this is frustrating (and odd, I think) is that if I use AViewer
to inspect MSAA and/or IAccessible2, I can see that the title attribute is
being registered properly as both an accessible name and description in
both browsers.
I tried a number of other experiments using various techniques I thought
might work, but none does -- ARIA label, labelledby, describedby in various
combinations -- yet each registers as expected in MSAA and/or IAccessible2.
Here's a test page:
https://dl.dropboxusercontent.com/u/4904309/experiments/abbr-test.html(There's
a little table experiment that uses the deprecated abbr attribute
-- JAWS still like this, NVDA not so much.)
Questions:
Do I still emphasize to people the importance of using the abbr tag and
title attribute -- the problem is with the screen reader, not the HTML?
Does it work anywhere else (in VoiceOver on iOS/Mac)?
Is there some technique to make it work that I'm missing?
Are there techniques in NVDA and/or JAWS to inspect abbr element attributes
that I am unaware of?
Cheers,
---
Ken Petri
From: Joe Chidzik
Date: Tue, Sep 17 2013 2:01AM
Subject: Re: usage of abbreviation tag
← Previous message | Next message →
> Questions:
> Do I still emphasize to people the importance of using the abbr tag and title
> attribute -- the problem is with the screen reader, not the HTML?
Note also that the abbr element is inaccessible for keyboard users.
I generally advise that when an acronymabbreviation is used for the first time on a page, it is expanded in full e.g. BBC (British Broadcasting Corporation). This approach is accessible to screenreader users, and also gives keyboard users access to the expansion.
Another, accessible, alternative, is using a pure CSS tooltip which uses the :focus pseudoclass in addition to :hover so that it is accessible to keyboard and mouse users, as well as screenreader users.
Joe
From: Olaf Drümmer
Date: Tue, Sep 17 2013 2:19AM
Subject: Re: usage of abbreviation tag
← Previous message | Next message →
With abbr it is the same as with a lot of other aspects - the "problem to be solved" should rather be addressed on the editorial level, than on the technical level. If - as Joe describes - the abbreviation is explained in the text by providing the full text on its first occurrence on the page, nothing else will be needed. Editorial solutions have the advantage that they are technology-agnotisc, and good writers get it right anyway (because it is also useful for users without disabilities). They even continue to work when you print out the page or copy and paste the text into your favourite text editor.
From my point of view only looking at technical band-aids is a waste of scarce and precious resources, and tends to help only in very specific circumstances (screen reader) and misses just about every other type of access (keyboard driven access, magnification, text customisation,
.). Instead it would usually cost much less to get the content right, or to think of solutions that work always, whether a user has a disability or two or not.
Olaf
Am 17 Sep 2013 um 10:01 schrieb Joe Chidzik < = EMAIL ADDRESS REMOVED = >:
>> Questions:
>> Do I still emphasize to people the importance of using the abbr tag and title
>> attribute -- the problem is with the screen reader, not the HTML?
>
> Note also that the abbr element is inaccessible for keyboard users.
>
> I generally advise that when an acronymabbreviation is used for the first time on a page, it is expanded in full e.g. BBC (British Broadcasting Corporation). This approach is accessible to screenreader users, and also gives keyboard users access to the expansion.
>
> Another, accessible, alternative, is using a pure CSS tooltip which uses the :focus pseudoclass in addition to :hover so that it is accessible to keyboard and mouse users, as well as screenreader users.
>
> Joe
> > >
From: Jonathan Metz
Date: Tue, Sep 17 2013 7:53AM
Subject: Re: usage of abbreviation tag
← Previous message | Next message →
The notion to announce acronyms the first time that you use them from an
editorial perspective is fine unless the authors adhere to AP (Associated
Press) Style guidelines. Current AP Style does not allow editors to
announce acronyms.
Another stupid thing AP Style does is eliminates the Oxford Comma (aka the
series comma), which screws up the meaning for a sentence. But I digress.
If Ken¹s content creators must use AP style, he will need to use
³technical band-aids² to fix the idiocy of editors using correct style
guidelines.
What do we do if we can¹t leave it up to someone else to fix?
Thanks,
Jon
On 9/17/13 4:19 AM, "Olaf Drümmer" < = EMAIL ADDRESS REMOVED = > wrote:
>With abbr it is the same as with a lot of other aspects - the "problem to
>be solved" should rather be addressed on the editorial level, than on the
>technical level. If - as Joe describes - the abbreviation is explained in
>the text by providing the full text on its first occurrence on the page,
>nothing else will be needed. Editorial solutions have the advantage that
>they are technology-agnotisc, and good writers get it right anyway
>(because it is also useful for users without disabilities). They even
>continue to work when you print out the page or copy and paste the text
>into your favourite text editor.
>
>From my point of view only looking at technical band-aids is a waste of
>scarce and precious resources, and tends to help only in very specific
>circumstances (screen reader) and misses just about every other type of
>access (keyboard driven access, magnification, text customisation, .).
>Instead it would usually cost much less to get the content right, or to
>think of solutions that work always, whether a user has a disability or
>two or not.
>
>Olaf
>
>
>
>Am 17 Sep 2013 um 10:01 schrieb Joe Chidzik
>< = EMAIL ADDRESS REMOVED = >:
>
>>> Questions:
>>> Do I still emphasize to people the importance of using the abbr tag
>>>and title
>>> attribute -- the problem is with the screen reader, not the HTML?
>>
>> Note also that the abbr element is inaccessible for keyboard users.
>>
>> I generally advise that when an acronymabbreviation is used for the
>>first time on a page, it is expanded in full e.g. BBC (British
>>Broadcasting Corporation). This approach is accessible to screenreader
>>users, and also gives keyboard users access to the expansion.
>>
>> Another, accessible, alternative, is using a pure CSS tooltip which
>>uses the :focus pseudoclass in addition to :hover so that it is
>>accessible to keyboard and mouse users, as well as screenreader users.
>>
>> Joe
>> >> >> >
>>>
From: Ken Petri
Date: Tue, Sep 17 2013 11:32AM
Subject: Re: usage of abbreviation tag
← Previous message | Next message →
The fact that title on abbreviation doesn't work with keyboard focus is
perhaps understandable, since abbreviations are not in the tab order. (I
guess that's the justification??) But even if you put them in the tab order
(not something I'm recommending but technically easy to pull off with
tabindex="0" the title still does not display (except in IE 10! -- maybe
earlier versions?).
Overall the display of title on abbr requires a mouse hover -- not touch,
not cursor focus. So I guess I have to agree with Olaf and Joe that
following the editorial practice of expanding the first instance in the
text is the most universally usable option.
However, what about those situations where an accepted standard argues
against that, like Jon points out, or the author just forgets?
BTW, I added a CCS generated-content example. I made it focusable using the
tabindex=0 trick. Now with keyboard tab navigation you can see the tooltip.
My implementation is not robust. Plus you get the unfortunate side effect
that NVDA says the abbr is "clickable," and JAWS says it is both
"clickable" and that one can "edit" it. Looks like you just can't win with
a simple implementation. Hans Hillen's jQuery UI tooltip seems to work
well, though: http://hanshillen.github.io/jqtest/#goto_tooltip. And Dojo
has something similar.
Thanks for the feedback.
- ken
From: Jukka K. Korpela
Date: Wed, Sep 18 2013 12:46AM
Subject: Re: usage of abbreviation tag
← Previous message | Next message →
2013-09-17 11:01, Joe Chidzik wrote:
> Note also that the abbr element is inaccessible for keyboard users.
It depends. If you mean access to the value of the title attribute, then
it can be arranged (e.g., by setting tabindex on the element and using
abbr:focus:after). But it gets ugly, and the implementation of title
attributes as "tooltips" in graphic browsers is just awful - a horror
example really (tiny font, not controllable by the user or by the
author, and the tooltip disappearing after some seconds).
> I generally advise that when an acronymabbreviation is used for the
> first time on a page, it is expanded in full e.g. BBC (British
> Broadcasting Corporation). This approach is accessible to
> screenreader users, and also gives keyboard users access to the
> expansion.
That's a good general principle, and the only really accessible way -
though the question still arises how to handle that problem that many
people keep forgetting things. They read an explanation, but they have
forgotten when they see the abbreviation used a few pages later. And
there's also the problem of non-linear reading: people can jump into any
point in the text. You can use links to deal with this, but caution is
needed. There is such a thing as over-linking. Too many links confuse
people, especially since there is often no quick way of seeing or
hearing what the link is really about.
Specifically, I would rarely spell out an abbreviation like "BBC". It is
probably better known than its expansion. And if the text is not in
English, then it is probably better to explain, in the language of the
text, what BBC is, rather than show the English expansion.
> Another, accessible, alternative, is using a pure CSS tooltip which
> uses the :focus pseudoclass in addition to :hover so that it is
> accessible to keyboard and mouse users, as well as screenreader
> users.
Yes, that makes much more sense than browsers' "tooltips". But then you
have the problem where to put the CSS tooltip text. It's not
straightforward, and it opens an accessibility problem rather than
solves one. What I mean is that CSS tooltips can be nice, but they are
an approach to presenting information in an interactive way, and then
you need to worry about making that accessible.
Yucca
From: Olaf Drümmer
Date: Wed, Sep 18 2013 1:44AM
Subject: Re: usage of abbreviation tag
← Previous message | Next message →
Hi Jukka,
Am 18 Sep 2013 um 08:46 schrieb "Jukka K. Korpela" < = EMAIL ADDRESS REMOVED = >:
> That's a good general principle, and the only really accessible way -
> though the question still arises how to handle that problem that many
> people keep forgetting things. They read an explanation, but they have
> forgotten when they see the abbreviation used a few pages later. And
> there's also the problem of non-linear reading: people can jump into any
> point in the text. You can use links to deal with this, but caution is
> needed. There is such a thing as over-linking. Too many links confuse
> people, especially since there is often no quick way of seeing or
> hearing what the link is really about.
>
> Specifically, I would rarely spell out an abbreviation like "BBC". It is
> probably better known than its expansion. And if the text is not in
> English, then it is probably better to explain, in the language of the
> text, what BBC is, rather than show the English expansion.
all this has nothing to do with accessibility!
It may have something to do with usability or with being nice towards a consumer of content, but nothing at all with accessibility.
Disability or not - a user may have to use the same extra effort to find out what something means if he / she doesn't understand it right away, whether that's an abbreviation, a technical term, the name of a person or city, or
- the slight exception being cognitive disabilities - but for these work has to be done on the editorial level anyway.
Olaf
From: Jukka K. Korpela
Date: Wed, Sep 18 2013 2:20AM
Subject: Re: usage of abbreviation tag
← Previous message | Next message →
2013-09-18 10:44, Olaf Drümmer wrote:
> Am 18 Sep 2013 um 08:46 schrieb "Jukka K. Korpela" < = EMAIL ADDRESS REMOVED = >:
>
>> That's a good general principle, and the only really accessible way -
>> though the question still arises how to handle that problem that many
>> people keep forgetting things. They read an explanation, but they have
>> forgotten when they see the abbreviation used a few pages later. And
>> there's also the problem of non-linear reading: people can jump into any
>> point in the text. You can use links to deal with this, but caution is
>> needed. There is such a thing as over-linking. Too many links confuse
>> people, especially since there is often no quick way of seeing or
>> hearing what the link is really about.
>>
>> Specifically, I would rarely spell out an abbreviation like "BBC". It is
>> probably better known than its expansion. And if the text is not in
>> English, then it is probably better to explain, in the language of the
>> text, what BBC is, rather than show the English expansion.
>
> all this has nothing to do with accessibility!
Oh, it does.
> Disability or not - a user may have to use the same extra effort
> to find out what something means if he / she doesn't understand it
right away,
> whether that's an abbreviation, a technical term, the name of a person or city,
Surely not the same extra effort.
I would normally expect people to know "BBC" without explanations. On
the other hand, some people would not immediately understand it even if
I gave both the expansion and an explanation in their native language.
The concept of a broadcasting corporation is at a high level of
abstraction. If an explanation is needed and given, then some people
will remember it well, others have to search back and may get frustrated
especially if the text contains many abbreviations.
So there is a challenge: how to present things so that they are
accessible to all (including people who easily forget what you just told
them), yet natural and smooth reading to people know the abbreviations
well and would find it odd to see very common abbreviations explained.
> or
- the slight exception being cognitive disabilities
Which constitute a significant part of disabilities.
Yucca
From: Olaf Drümmer
Date: Wed, Sep 18 2013 2:49AM
Subject: Re: usage of abbreviation tag
← Previous message | Next message →
Hi Jukka,
let me make clear that I believe that you and I agree at least 99.9% - this exchange of emails is just to go through some interesting exercises
!
Am 18 Sep 2013 um 10:20 schrieb Jukka K. Korpela < = EMAIL ADDRESS REMOVED = >:
> So there is a challenge: how to present things so that they are
> accessible to all
When working on PDF/UA (the ISO standard for accessible PDF documents, ISO 14289-1:2012, where UA stands for 'universal accessibility') we had a discussion in the PDF/UA working grouping in ISO TC 171 (ISO stands for International Organisation for Standardisation - see www.iso.org for more info - and TC is a shorthand for Technical Committee), how far we should go in requiring certain accessibility aspects. We essentially arrived at the conclusion that it is not the task of a technical standard like PDF/UA, or actually most of WCAG, to fix just about anything.
If a PDF document consists of difficult to understand garbage, it is not he task of PDF/UA to require that the garbage is "un-garbaged", and that it is made easy to understand, but only, to make this garbage as accessible to people with disabilities, as it is to people without disabilities. So it is important to require that reading order is defined, that for non-text content text equivalents are provided etc. But there is no requirement that states "Garbage quality documents must be rewritten such that they become quality content that is easy to understand.".
Now, there might be situations, where such garbage documents or garbage content are unacceptable - like important websites from government agencies (and ideally also any website that is essential to daily life) - but it would be impossible (and even not completely desirable) to enforce that people stop producing garbage quality content. It would make a lot of sense though, that - as much as possible - any content (garbage quality or not) is provided in a fashion that it can be accessed similarly well by people with and without disabilities.
Olaf
PS: I intentionally did not make it clear above that PDF in this email does not stand for Parkinson Disease Foundation, but rather for Portable Document Format, an electronic document format invented by Adobe Systems and first published in 1993, and meanwhile, in 2008, ratified as an international standard by ISO (ISO 32000).
From: Jonathan Metz
Date: Wed, Sep 18 2013 9:13AM
Subject: Re: usage of abbreviation tag
← Previous message | Next message →
Hi Olaf,
If you focus on the disabilities that can easily be satiated by technical
means, current PDF/UA (and even WCAG if you ignore AAA provisions) does a
smashing job. But there are a number of IWD (Individuals with
Disabilities) who experience some random nebulous disability that lumps
them in with a pool of other ambiguous impairments. The level of
accessibility these IWD require aren¹t typically solved¹ via programatic
means.
I have come across a few people who argue that WCAG only serves people who
have a visual impairment, and doesn¹t do enough for people who experience
some other form of disability. There is some truth in this complaint. One
could argue that if it can¹t be figured out programmatically, then extra
work would mean rewriting the junk that¹s in a document. Many of the AAA
provisions of WCAG 2.0 would be very beneficial to Individuals with
Cognitive Impairments. However, these will probably be most ignored since
they¹re never required.
I would argue that IWD who experience ³Cognitive Impairments (CI)² (quoted
because this could mean a broad range of disabilities) are oft forgotten
when it comes to making something accessible, because it is probably
extremely difficult (if not downright impossible) to make it accessible
via programmatic means. People who have hypersensitive touch, for example,
might not require a screen reader to assess a document.
I was late to the game of PDF/UA, which is unfortunate; because I would
have liked to take part in the debate of ³How far we should go to make it
accessible.² Making sure that we only focus on the things that can make it
accessible via computer software does not really make it ³Universal[ly]
Accessible,² but rather ³As Accessible.² Most of the provisions of ISO
14289 are usable only for software developers, not people who make things
accessible for whatever demographic for whom they are trying to make it
accessible.
Expanding an uncommon acronym isn¹t rewriting a poorly written document,
but instead going an extra step to benefit those with CI. This is
particularly true with government documents, which are riddled with
acronyms. I would argue that people with CI would not benefiting from a
³slight exception² since they make up 20% of the US population.
On 9/18/13 4:49 AM, "Olaf Drümmer" < = EMAIL ADDRESS REMOVED = > wrote:
>Hi Jukka,
>
>let me make clear that I believe that you and I agree at least 99.9% -
>this exchange of emails is just to go through some interesting exercises!
>
>Am 18 Sep 2013 um 10:20 schrieb Jukka K. Korpela < = EMAIL ADDRESS REMOVED = >:
>
>> So there is a challenge: how to present things so that they are
>> accessible to all
>
>When working on PDF/UA (the ISO standard for accessible PDF documents,
>ISO 14289-1:2012, where UA stands for 'universal accessibility') we had a
>discussion in the PDF/UA working grouping in ISO TC 171 (ISO stands for
>International Organisation for Standardisation - see www.iso.org for more
>info - and TC is a shorthand for Technical Committee), how far we should
>go in requiring certain accessibility aspects. We essentially arrived at
>the conclusion that it is not the task of a technical standard like
>PDF/UA, or actually most of WCAG, to fix just about anything.
>
>If a PDF document consists of difficult to understand garbage, it is not
>he task of PDF/UA to require that the garbage is "un-garbaged", and that
>it is made easy to understand, but only, to make this garbage as
>accessible to people with disabilities, as it is to people without
>disabilities. So it is important to require that reading order is
>defined, that for non-text content text equivalents are provided etc. But
>there is no requirement that states "Garbage quality documents must be
>rewritten such that they become quality content that is easy to
>understand.".
>
>Now, there might be situations, where such garbage documents or garbage
>content are unacceptable - like important websites from government
>agencies (and ideally also any website that is essential to daily life) -
>but it would be impossible (and even not completely desirable) to enforce
>that people stop producing garbage quality content. It would make a lot
>of sense though, that - as much as possible - any content (garbage
>quality or not) is provided in a fashion that it can be accessed
>similarly well by people with and without disabilities.
>
>Olaf
>
>PS: I intentionally did not make it clear above that PDF in this email
>does not stand for Parkinson Disease Foundation, but rather for Portable
>Document Format, an electronic document format invented by Adobe Systems
>and first published in 1993, and meanwhile, in 2008, ratified as an
>international standard by ISO (ISO 32000).
>>>
From: Olaf Drümmer
Date: Wed, Sep 18 2013 10:17AM
Subject: Re: usage of abbreviation tag
← Previous message | Next message →
Hi Jonathan,
let me clarify something first: I am definitely not intending to say that that certain groups of IWDs (individuals with disabilities) are less relevant than others. And I also agree that there is too often too much focus on visual impairments and how to address them using screen readers, while most other types of disabilities are silently skipped.
I would nevertheless like to claim that certain aspects need to be addressed on the content / editorial level, and should not be addressed on some technical level. To ride the horse of abbreviations and expansions again:
provide enough information to let people understand an abbreviation should happen on the **editorial level** (i.e. simply make the explanation or expansion text part of the regular text), **not** on a **technical level** (like a usually hidden piece of information carrying the expansion, requiring some extra software function to reveal it).
Neither WCAG nor PDF/UA are the right place to define these, as the underlying issue is not technology related, rather, it is content related, and has to be solved on the editorial level. We need something like the "The Associated Press Stylebook", but targeting creation of content with disabilities in mind. Such a style guide would be mostly technology independent, but could also take into account technology. Just an example: writers should prefer wording like "as is shown in table 321" instead of "as is shown in the table to the right". Writers could also learn that it is useful to have captions for images that provide sufficient information such that looking at just the image and the caption, readers could make sense of the image, whether they happen to be sighted or non-sighted users or users from a different cultural background or what else.
I think it would be wrong to sneak such a style guide into technology centric standards or guidelines like WCAG or PDF/UA. But I also think, such a style guide is desperately needed, in order to not give the impression editorial problems could be solved on a technology level.
There is also another important aspect when it comes to improving accessibility: a lot of the issues that currently some try to solve by injecting abbreviation attributes/ expansion texts could be solved by reader software. Why not build a software that offers an explanation for a given abbreviation in a text a person with an OFS ("often forgets stuff") disability is currently reading? This reader could look up the abbreviation in an online dictionary. Instead of forcing lots of people to figure out how to squeeze all kinds of expansion texts into their content, invest in such online dictionaries, get the reader software right, and be done with it. Scales much better, and solves the problem once instead of solving it again and again and again
.
I think we need to make ourselves much more aware what kind of problem we are having in front of us in a given situation, and where it is best solved:
- on the technology level?
- on the editorial level?
- on the content (/ content creation) side?
- by means of getting the tools right that authors use to create content (in a well designed web content system it might be feasible to make it virtually impossible to create technically inaccessible content, and the system could also help authors to avoid editorial barriers, like overly long sentences)?
- on the side of the tools used to consume content?
- by the original author? (One important thing to keep in mind: most authors/content creators are "ordinary people", not accessibility specialists, and most of the time not even content creation specialists - most of them would not speak of themselves as authors, but still they create and share content all the time. How many people posting on this list would think of themselves as "authors"? Yet we all author content all the time...)
- by a specialist post-processing output from authors?
Olaf
Am 18 Sep 2013 um 17:13 schrieb Jonathan Metz < = EMAIL ADDRESS REMOVED = >:
> Hi Olaf,
>
>
> If you focus on the disabilities that can easily be satiated by technical
> means, current PDF/UA (and even WCAG if you ignore AAA provisions) does a
> smashing job. But there are a number of IWD (Individuals with
> Disabilities) who experience some random nebulous disability that lumps
> them in with a pool of other ambiguous impairments. The level of
> accessibility these IWD require aren¹t typically solved¹ via programatic
> means.
>
> I have come across a few people who argue that WCAG only serves people who
> have a visual impairment, and doesn¹t do enough for people who experience
> some other form of disability. There is some truth in this complaint. One
> could argue that if it can¹t be figured out programmatically, then extra
> work would mean rewriting the junk that¹s in a document. Many of the AAA
> provisions of WCAG 2.0 would be very beneficial to Individuals with
> Cognitive Impairments. However, these will probably be most ignored since
> they¹re never required.
>
> I would argue that IWD who experience ³Cognitive Impairments (CI)² (quoted
> because this could mean a broad range of disabilities) are oft forgotten
> when it comes to making something accessible, because it is probably
> extremely difficult (if not downright impossible) to make it accessible
> via programmatic means. People who have hypersensitive touch, for example,
> might not require a screen reader to assess a document.
>
>
> I was late to the game of PDF/UA, which is unfortunate; because I would
> have liked to take part in the debate of ³How far we should go to make it
> accessible.² Making sure that we only focus on the things that can make it
> accessible via computer software does not really make it ³Universal[ly]
> Accessible,² but rather ³As Accessible.² Most of the provisions of ISO
> 14289 are usable only for software developers, not people who make things
> accessible for whatever demographic for whom they are trying to make it
> accessible.
>
> Expanding an uncommon acronym isn¹t rewriting a poorly written document,
> but instead going an extra step to benefit those with CI. This is
> particularly true with government documents, which are riddled with
> acronyms. I would argue that people with CI would not benefiting from a
> ³slight exception² since they make up 20% of the US population.
>
>
> On 9/18/13 4:49 AM, "Olaf Drümmer" < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi Jukka,
>>
>> let me make clear that I believe that you and I agree at least 99.9% -
>> this exchange of emails is just to go through some interesting exercises!
>>
>> Am 18 Sep 2013 um 10:20 schrieb Jukka K. Korpela < = EMAIL ADDRESS REMOVED = >:
>>
>>> So there is a challenge: how to present things so that they are
>>> accessible to all
>>
>> When working on PDF/UA (the ISO standard for accessible PDF documents,
>> ISO 14289-1:2012, where UA stands for 'universal accessibility') we had a
>> discussion in the PDF/UA working grouping in ISO TC 171 (ISO stands for
>> International Organisation for Standardisation - see www.iso.org for more
>> info - and TC is a shorthand for Technical Committee), how far we should
>> go in requiring certain accessibility aspects. We essentially arrived at
>> the conclusion that it is not the task of a technical standard like
>> PDF/UA, or actually most of WCAG, to fix just about anything.
>>
>> If a PDF document consists of difficult to understand garbage, it is not
>> he task of PDF/UA to require that the garbage is "un-garbaged", and that
>> it is made easy to understand, but only, to make this garbage as
>> accessible to people with disabilities, as it is to people without
>> disabilities. So it is important to require that reading order is
>> defined, that for non-text content text equivalents are provided etc. But
>> there is no requirement that states "Garbage quality documents must be
>> rewritten such that they become quality content that is easy to
>> understand.".
>>
>> Now, there might be situations, where such garbage documents or garbage
>> content are unacceptable - like important websites from government
>> agencies (and ideally also any website that is essential to daily life) -
>> but it would be impossible (and even not completely desirable) to enforce
>> that people stop producing garbage quality content. It would make a lot
>> of sense though, that - as much as possible - any content (garbage
>> quality or not) is provided in a fashion that it can be accessed
>> similarly well by people with and without disabilities.
>>
>> Olaf
>>
>> PS: I intentionally did not make it clear above that PDF in this email
>> does not stand for Parkinson Disease Foundation, but rather for Portable
>> Document Format, an electronic document format invented by Adobe Systems
>> and first published in 1993, and meanwhile, in 2008, ratified as an
>> international standard by ISO (ISO 32000).
>> >> >> >
> > >
From: Jonathan Metz
Date: Wed, Sep 18 2013 12:45PM
Subject: Re: usage of abbreviation tag
← Previous message | No next message
Howdy Olaf,
I apologize if it seemed as if I was implying that you are in favor of one
group of IWDs over another. Having conversed on here, LinkedIn and PDF/UA
I know the opposite to be the case.
I believe our difference might lie in the fact that I don't believe
separating content from technical ability is the best course of action. On
some level, altering the way one provides content will be helpful to
individuals with disabilities (IWD). Yet I believe that technical
capabilities should be there to assist in making things more accessible.
Providing expansion text for acronyms is akin to providing alternate text
to images. At face value, it's just some kind of content that's on the
page that the user is left to determine the meaning of. Providing more
information about it allows the user to understand that there is something
significant about the content.
If technology is also there to assist in making content more accessible,
then PDF/UA and WCAG should address that, in my opinion. I don't think
that as technology developers we should wash our hands of accessibility if
content providers can't get something right.
In a lot of cases (particularly for US Government documents), it's not so
much a case of not doing something correctly but doing things the way
content providers are directed to do it. For example, an agency I am
working with uses AP Style for all their documents. There is nothing wrong
with this, but in doing so, the announcement of acronyms is prohibited.
For much of the government, agencies simply let this go since the usual
demographic is other gov or military people, and most know what some
obscure acronym is. However, many documents are intended for family
members of government personnel. Those people have NO idea what the
alphabet soup refers to.
I agree with you that most people are not exactly âprofessional' authors
but rather content producers. But most people who work on the technical
side of things (designers or developers, programmers, etc) are pros at
what they do. Since that's the case, I think they should pick up the slack
and make things a little easier for IWD since they know how to do so.
Thanks,
Jon
On 9/18/13 12:17 PM, "Olaf Drümmer" < = EMAIL ADDRESS REMOVED = > wrote:
>Hi Jonathan,
>
>let me clarify something first: I am definitely not intending to say that
>that certain groups of IWDs (individuals with disabilities) are less
>relevant than others. And I also agree that there is too often too much
>focus on visual impairments and how to address them using screen readers,
>while most other types of disabilities are silently skipped.
>
>I would nevertheless like to claim that certain aspects need to be
>addressed on the content / editorial level, and should not be addressed
>on some technical level. To ride the horse of abbreviations and
>expansions again:
>
>provide enough information to let people understand an abbreviation
>should happen on the **editorial level** (i.e. simply make the
>explanation or expansion text part of the regular text), **not** on a
>**technical level** (like a usually hidden piece of information carrying
>the expansion, requiring some extra software function to reveal it).
>
>Neither WCAG nor PDF/UA are the right place to define these, as the
>underlying issue is not technology related, rather, it is content
>related, and has to be solved on the editorial level. We need something
>like the "The Associated Press Stylebook", but targeting creation of
>content with disabilities in mind. Such a style guide would be mostly
>technology independent, but could also take into account technology. Just
>an example: writers should prefer wording like "as is shown in table 321"
>instead of "as is shown in the table to the right". Writers could also
>learn that it is useful to have captions for images that provide
>sufficient information such that looking at just the image and the
>caption, readers could make sense of the image, whether they happen to be
>sighted or non-sighted users or users from a different cultural
>background or what else.
>
>I think it would be wrong to sneak such a style guide into technology
>centric standards or guidelines like WCAG or PDF/UA. But I also think,
>such a style guide is desperately needed, in order to not give the
>impression editorial problems could be solved on a technology level.
>
>There is also another important aspect when it comes to improving
>accessibility: a lot of the issues that currently some try to solve by
>injecting abbreviation attributes/ expansion texts could be solved by
>reader software. Why not build a software that offers an explanation for
>a given abbreviation in a text a person with an OFS ("often forgets
>stuff") disability is currently reading? This reader could look up the
>abbreviation in an online dictionary. Instead of forcing lots of people
>to figure out how to squeeze all kinds of expansion texts into their
>content, invest in such online dictionaries, get the reader software
>right, and be done with it. Scales much better, and solves the problem
>once instead of solving it again and again and again ….
>
>I think we need to make ourselves much more aware what kind of problem we
>are having in front of us in a given situation, and where it is best
>solved:
>- on the technology level?
>- on the editorial level?
>- on the content (/ content creation) side?
>- by means of getting the tools right that authors use to create content
>(in a well designed web content system it might be feasible to make it
>virtually impossible to create technically inaccessible content, and the
>system could also help authors to avoid editorial barriers, like overly
>long sentences)?
>- on the side of the tools used to consume content?
>- by the original author? (One important thing to keep in mind: most
>authors/content creators are "ordinary people", not accessibility
>specialists, and most of the time not even content creation specialists -
>most of them would not speak of themselves as authors, but still they
>create and share content all the time. How many people posting on this
>list would think of themselves as "authors"? Yet we all author content
>all the time...)
>- by a specialist post-processing output from authors?
>
>
>Olaf
>
>
>Am 18 Sep 2013 um 17:13 schrieb Jonathan Metz
>< = EMAIL ADDRESS REMOVED = >:
>
>> Hi Olaf,
>>
>>
>> If you focus on the disabilities that can easily be satiated by
>>technical
>> means, current PDF/UA (and even WCAG if you ignore AAA provisions) does
>>a
>> smashing job. But there are a number of IWD (Individuals with
>> Disabilities) who experience some random nebulous disability that lumps
>> them in with a pool of other ambiguous impairments. The level of
>> accessibility these IWD require aren¹t typically Åsolved¹ via
>>programatic
>> means.
>>
>> I have come across a few people who argue that WCAG only serves people
>>who
>> have a visual impairment, and doesn¹t do enough for people who
>>experience
>> some other form of disability. There is some truth in this complaint.
>>One
>> could argue that if it can¹t be figured out programmatically, then extra
>> work would mean rewriting the junk that¹s in a document. Many of the AAA
>> provisions of WCAG 2.0 would be very beneficial to Individuals with
>> Cognitive Impairments. However, these will probably be most ignored
>>since
>> they¹re never required.
>>
>> I would argue that IWD who experience ³Cognitive Impairments (CI)²
>>(quoted
>> because this could mean a broad range of disabilities) are oft forgotten
>> when it comes to making something accessible, because it is probably
>> extremely difficult (if not downright impossible) to make it accessible
>> via programmatic means. People who have hypersensitive touch, for
>>example,
>> might not require a screen reader to assess a document.
>>
>>
>> I was late to the game of PDF/UA, which is unfortunate; because I would
>> have liked to take part in the debate of ³How far we should go to make
>>it
>> accessible.² Making sure that we only focus on the things that can make
>>it
>> accessible via computer software does not really make it ³Universal[ly]
>> Accessible,² but rather ³As Accessible.² Most of the provisions of ISO
>> 14289 are usable only for software developers, not people who make
>>things
>> accessible for whatever demographic for whom they are trying to make it
>> accessible.
>>
>> Expanding an uncommon acronym isn¹t rewriting a poorly written document,
>> but instead going an extra step to benefit those with CI. This is
>> particularly true with government documents, which are riddled with
>> acronyms. I would argue that people with CI would not benefiting from a
>> ³slight exception² since they make up 20% of the US population.
>>
>>
>> On 9/18/13 4:49 AM, "Olaf Drümmer" < = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> Hi Jukka,
>>>
>>> let me make clear that I believe that you and I agree at least 99.9% -
>>> this exchange of emails is just to go through some interesting
>>>exercisesÅ !
>>>
>>> Am 18 Sep 2013 um 10:20 schrieb Jukka K. Korpela < = EMAIL ADDRESS REMOVED = >:
>>>
>>>> So there is a challenge: how to present things so that they are
>>>> accessible to all
>>>
>>> When working on PDF/UA (the ISO standard for accessible PDF documents,
>>> ISO 14289-1:2012, where UA stands for 'universal accessibility') we
>>>had a
>>> discussion in the PDF/UA working grouping in ISO TC 171 (ISO stands for
>>> International Organisation for Standardisation - see www.iso.org for
>>>more
>>> info - and TC is a shorthand for Technical Committee), how far we
>>>should
>>> go in requiring certain accessibility aspects. We essentially arrived
>>>at
>>> the conclusion that it is not the task of a technical standard like
>>> PDF/UA, or actually most of WCAG, to fix just about anything.
>>>
>>> If a PDF document consists of difficult to understand garbage, it is
>>>not
>>> he task of PDF/UA to require that the garbage is "un-garbaged", and
>>>that
>>> it is made easy to understand, but only, to make this garbage as
>>> accessible to people with disabilities, as it is to people without
>>> disabilities. So it is important to require that reading order is
>>> defined, that for non-text content text equivalents are provided etc.
>>>But
>>> there is no requirement that states "Garbage quality documents must be
>>> rewritten such that they become quality content that is easy to
>>> understand.".
>>>
>>> Now, there might be situations, where such garbage documents or garbage
>>> content are unacceptable - like important websites from government
>>> agencies (and ideally also any website that is essential to daily
>>>life) -
>>> but it would be impossible (and even not completely desirable) to
>>>enforce
>>> that people stop producing garbage quality content. It would make a lot
>>> of sense though, that - as much as possible - any content (garbage
>>> quality or not) is provided in a fashion that it can be accessed
>>> similarly well by people with and without disabilities.
>>>
>>> Olaf
>>>
>>> PS: I intentionally did not make it clear above that PDF in this email
>>> does not stand for Parkinson Disease Foundation, but rather for
>>>Portable
>>> Document Format, an electronic document format invented by Adobe
>>>Systems
>>> and first published in 1993, and meanwhile, in 2008, ratified as an
>>> international standard by ISO (ISO 32000).
>>> >>> >>> >>
>> >> >> >
>>>