WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: usage of abbreviation tag

for

From: Jonathan Metz
Date: Sep 18, 2013 12:45PM

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