RE: Thoughts on taxonomy development

When creating our taxonomy we need to define:

The object type
What objects they contain (if anything)
How objects relate to each other and within the context of the container
they are in
How do we navigate within and among them
What are their object properties.

Starting with core concepts that covers these objectives is a very good
start. We should also determine the containment model. Can anything contain
anything? That can lead to a lot of confusion by end users. We have core
concepts in ARIA that start with abstract roles that subclass into greater
detail - many of these are things that we expose to the end user.

What will be challenging for us is that industry has not done a sufficient
job in describing to assistive technologies how to present them to
different user impairments. This is where we will be breaking new ground.
With ARIA 1.0 we could build off of what we did in the earliest desktop
screen readers to today's desktop UI component concepts. Drawings, Charts,
etc. is a bit different.

I think we are also going to want to decide how we should present the
information by ATs. ... Is it something an AT could look at and summarize?
This is as important for screen reader users as it is for a mobile device
users with a small screen. ... pinching and squeezing becomes a

A good exercise would be to try to merge Doug and Fred's charts into a
class hierarchy with properties to see what works and what does not work in
the merger.


Rich Schwerdtfeger

From:	"White, Jason J" <>
To:	Fred Esch/Arlington/IBM@IBMUS, ""
Date:	12/22/2014 04:01 PM
Subject:	RE: Thoughts on taxonomy development

>-----Original Message-----
>Our goal is to cover a wide variety of graphics families. The straw man
>taxonomy covers statistical graphs, maps and technical drawings as that is
>what I am familiar with. It sounds like STEM/instructional diagrams,
>mathematical functions and UML are some families that we can bring in. We
>will need someone to identify a graphics family for inclusion and bring in
>concepts not already covered.  While each graphics family may have their
>lexicon, I believe there are a core group of concepts that will cover 85%
of our
>accessible graphics use cases.  I think our first cut at a taxonomy should
>geared toward identifying the core concepts.

I agree that identifying common concepts across graphic types is essential.
We ultimately need a carefully defined taxonomic hierarchy which captures
those core concepts and supports subsequent extension to cover a growing
variety of applications.
>Whether we try to describe the visual representation is debatable and I
>believe we can look at that aspect of accessible graphics, after finding
the core
>taxonomy.  To me, what information to provide for each concept is a first
>of detail, that we should do after identifying core concepts so we don't
>bogged down. My interest in what properties to have relate to being able
>produce accessible graphics automatically and have them read consistently
>assitive technology. Others may want more expansive descriptions that
>require human intervention. I believe we will have to be flexible and
allow a
>continuum of descriptions. But I would like to see us address that later.

SVG already provides direct support for certain geometric constructs,
raising the question of whether some of these should be conveyed to
assistive technologies in addition to, but not in place of, whatever
information the author supplies in accordance with the taxonomy. Lines,
curves and polygons, for example,, or at least those marked as significant
by the author, could have roles associated with them by default. In fact,
this raises a larger concern: it may well be desirable to associate
multiple roles with a graphical object, specifying for example that a given
shape is both a circle and that it represents a set in a Venn diagram. Both
levels of meaning can be important depending on the use case (the student
who is learning for the first time what a Venn diagram is arguably needs to
know both of these facts, whereas the more experienced student, or the
person approaching the diagram for professional purposes, generally wants
only to know the facts represented about sets and their relations).


This e-mail and any files transmitted with it may contain privileged or
confidential information. It is solely for use by the individual for whom
it is intended, even if addressed incorrectly. If you received this e-mail
in error, please notify the sender; do not disclose, copy, distribute, or
take any action in reliance on the contents of this information; and delete
it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.


Received on Friday, 2 January 2015 19:43:37 UTC