- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Fri, 2 Jan 2015 13:43:02 -0600
- To: "White, Jason J" <jjwhite@ets.org>
- Cc: Fred Esch <fesch@us.ibm.com>, "public-svg-a11y@w3.org" <public-svg-a11y@w3.org>
- Message-ID: <OF2F014942.40370F9B-ON86257DC1.006B5952-86257DC1.006C4F63@us.ibm.com>
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 non-starter. 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 Rich Schwerdtfeger From: "White, Jason J" <jjwhite@ets.org> To: Fred Esch/Arlington/IBM@IBMUS, "public-svg-a11y@w3.org" <public-svg-a11y@w3.org> 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 the >concepts not already covered. While each graphics family may have their own >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 be >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 level >of detail, that we should do after identifying core concepts so we don't get >bogged down. My interest in what properties to have relate to being able to >produce accessible graphics automatically and have them read consistently by >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. ________________________________
Attachments
- image/gif attachment: graycol.gif
Received on Friday, 2 January 2015 19:43:37 UTC