[Accessibility-handlers] Unified Use Cases for Expert Handlers (Final?) Draft 2.04

Neil Soiffer soiffer at alum.mit.edu
Mon Feb 4 11:02:04 PST 2008

A few more minor changes:

I suggest breaking the following up into two sentences and adding a few
words for clarity in the following:

> This plug-in standard will allow the expert software to provide enhanced,
> semantically rich access to specialized markup so that the AT can properly
> render (visually, aurally, and/or tactilely) and help users navigate the
> semantic meaning encoded in the specialized markup.
to become

> This plug-in standard will allow the expert software to provide enhanced,
> semantically rich access to specialized markup so that the AT can properly
> render the markup visually, aurally, and/or tactilely.  The plug-in would
> also help users navigate the semantic meaning encoded in the specialized
> markup.

Suggested wording for

> To better inform *[delineate? specify?]* what needs to be supported by an
> expert handler interface standard, the following sections discuss a number
> of use cases for an expert handler.
New wording:

> To provide some background as to what needs to be supported by an expert
> handler interface standard, the following sections discuss a number of use
> cases for an expert handler.

Last paragraph of navigation section:

> An example of such a plugin is needed so that one can evaluate what
> accessibility features need to be added to the existing editors.

If we want to keep a sentence like this, I suggest

> Accessibilities features needed for editing specialized markup have are
> not explored in this document due to lack of experience.

In the first paragraph of the braille seciton, the use of the word "MathML"
still seems out of place to me (I think it should be "math" or
"mathematics").  However, I understand that earlier in the paragraph it says
"specizalized data".  Suggest changing

> which affects how MathML<http://www.linux-foundation.org/en/Accessibility=
/Handlers/References/SMLs#mathml-info>is translated into a tactile form.

> which affects how mathematics (typically marked up using MathML<http://ww=
> is translated into a tactile form.


On Feb 3, 2008 1:58 PM, Gregory J. Rosmaita <unagi69 at concentric.net> wrote:

> aloha, all!
> apologies for the short turnaround time and notice, but the semi-final
> draft of the UUC document is available for final review at:
> http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/Unifie=
> and is included as plain text following my signature; note that i
> incorporated NS' indroductory paragraph, as submitted in:
> https://lists.linux-foundation.org/pipermail/accessibility-handlers/2008-=
> and a revised Footnote 2, which may need to be reorderd so that the last
> paragraph precedes the generalized list...
> comments, corrections, criticism, and feedback of any and all types are
> welcome -- please reply-to this post to log any of the aforementioned,
> so that we can discuss and integrate them into the finalized draft...
> thank you all for your participation, your input, your insights, and
> your prose -- i think we have a pretty tight document ready to be
> exposed to the wider world, but that'll be decided tomorrow at 1900h
> http://www.linux-foundation.org/en/Accessibility/Handlers/Meetings/Agenda=
> gregory.
> ---------------- BEGIN FINAL? UNIFIED USE CASES DRAFT ------------------
>  Unified Use Cases for Expert Handlers (Draft 2.04)
>   document status: internal draft -- this is a work-in-progress
>   revision date: 2008-02-03
>   previous versions: Draft 2.03b (2008-01-28), Draft 2.03 (2008-01-26),
>                      Draft 2.02b (2008-01-20), Draft 2.02a (2008-01-14),
>                      Draft 2.01 (2007-12-22)
>   authors: Pete Brunet, Vladmir Bulatov, Gregory J. Rosmaita, Janina
>            Sajka and Neil Soiffer (chair, Expert Handlers SIG)
>   edited and annotated by Gregory J. Rosmaita
>     _________________________________________________________________
>   please provide feedback on this draft to the Expert Handlers SIG
>   either via the Expert Handlers emailing list (preferred) or
>   directly to this document's "Discussion" page to which posted
>   comments will be appended by the editor. There is also a [1]Scratch
>   Pad for the Unified Use Cases which serves as a collection point for
>   issues and ideas related to expert handlers and its possible
>   implementations.
>     _________________________________________________________________
>   Contents
>        * 1. Unified Use Cases for Expert Handlers (Draft 2.04)
>               + 1.1 Introduction: What Are Expert Handlers?
>               + 1.2 Speech Output Use Cases for Expert Handlers
>               + 1.3 Alternative Input Use Cases
>               + 1.4 Navigability Use Cases
>               + 1.5 Magnification Use Cases
>               + 1.6 Braille Display, Embossing and Tactile Conversion Use
>                     Cases
>               + 1.7 Universal Use Cases
>                        o 1.7.1 Universal Use Case 1: Where Am I?
>                        o 1.7.2 Universal Use Case 2: Document Summary
>        * 2. Putting It All Together: Expert Handlers and the Flow of
>             Control
>        * 3. Footnotes
>     _________________________________________________________________
> Introduction: What Are Expert Handlers?
>   The purpose and responsibility of accessibility interfaces, such as
>   Microsoft Active Accessibility (MSAA) and IAccessible2 (IA2), is to
>   provide assistive technology (AT) with the ability to access and
>   interact with the information contained in an application. This allows
>   an AT to access the information in the application's DOM.
>   Interpreting, displaying, and navigating the information is the
>   responsibility of the AT. Generalized markup is sometimes complimented
>   by markup specifications that facilitate more semantically precise
>   content markup.
>   Assistive technology typically handles generalized content markup, but
>   does not know about specialized markup. Because of this, users of AT
>   are unable to access or navigate specialized markup effectively.
>   Generalized content markup (such as [2]HTML) is complimented by
>   markup specifications that facilitate more semantically precise
>   content markup. Examples of specialized, semantically precise markup
>   include [3]MathML and [4]MusicXML.
>   The Open A11y expert handlers SIG is exploring a standardized plug-in
>   mechanism to AT software. The goal of this plug-in standard is to
>   allow AT software to take advantage of expert software that
>   understands specialized markup. This plug-in standard will allow the
>   expert software to provide enhanced, semantically rich access to
>   specialized markup so that the AT can properly render (visually,
>   aurally, and/or tactilely) and help users navigate the semantic
>   meaning encoded in the specialized markup.
>   To better inform [delineate? specify?] what needs to be supported by
>   an expert handler interface standard, the following sections discuss a
>   number of use cases for an expert handler. The uses cases are divided
>   into various functionalities such as [5]speech, [6]navigation, and
>   [7]braille generation. The [8]last section discusses the options for
>   how an expert handler might fit into the sequence of events that
>   eventually results in a response to a user action.
>  Speech Output Use Cases for Expert Handlers
>   Computer users who are blind or severely visually impaired often use
>   assistive technology (AT) built around synthetic text to speech (TTS).
>   These AT applications are commonly called "screen readers." Screen
>   reader users listen to a synthetic voice rendering of on screen
>   content because they are physically unable to see this content on a
>   computer display monitor.
>   Because synthetic voice rendering is intrinsically temporal, whereas
>   on screen displays are (or can easily be made) static, various
>   strategies are provided by screen readers to allow users to tightly
>   control the alternative TTS rendering. Screen reader users often find
>   it useful, for instance, to skim through content until a particular
>   portion is located and then examine that portion in a more controlled
>   manner, perhaps word by word or even character by rendered character.
>   It is almost never useful to wait for a synthetic voice rendering that
>   begins at the upper left of the screen and proceeds left to right, row
>   by row, until it reaches the bottom because such a procedure is
>   temporally inefficient, requiring the user to strain to hear just the
>   portion desired in the midst of unsought content. Thus, screen readers
>   provide mechanisms that allow the user to focus anywhere in the
>   content and examine only that content which is of interest.
>   Screen readers have proven highly effective at providing their users
>   access to content which is intrinsically textual and linear in nature.
>   It is not hard to provide mechanisms to focus synthetic voice
>   rendering paragraph by paragraph, sentence by sentence, word by word,
>   or character by character.
>   Access to on screen widgets have also proven effective by rendering
>   that static content in list form, where the user can pick from a menu
>   of options using up and down arrow plus the enter key to indicate a
>   selection, in lieu of picking an icon on screen using a mouse.
>   Access to content arrayed in a table can also succeed by allowing the
>   AT to simulate the process a sighted user employs to consider tables.
>   In other words, mechanisms are provided to hear the contents of a cell
>   and also the row and column labels for that cell (which define the
>   cell's meaning).
>   Similar "smart" content rendering and navigation strategies are
>   required by screen reader users in more complex, nonlinear content
>   such as mathematical (chemical, biological, etc) expressions, music,
>   and graphical renderings. Because such content is generally the
>   province of knowledge domain experts and students, and not the domain
>   of most computer users, screen readers do not invest the significant
>   resources necessary to serve only a small portion of their customer
>   base with specialized routines for such content. Furthermore, the
>   general rendering and navigation strategies provided for linear
>   (textual), menu, and tabular content are woefully insufficient to
>   allow users to examine specific portions of such domain specific
>   expressions effectively. On the other hand domain specific markup
>   often does provide sufficient specificity so that the focus and
>   rendering needs of the screen reader can be well supported.
>   In order to gain effective access to such domain specific content
>   screen reader users require technology that can:
>     * Synthetically voice the expression in a logical order
>     * Allow the user to focus on particular, logical portions of
>       expressions possibly at several layers of granularity
>     * Appropriately voice specialized symbols and symbolic expressions
>     _________________________________________________________________
>  Alternative Input Use Cases
>   There are users with disabilities who do not require accomodation in
>   order to read domain specific markup. Rather, these users require
>   assistive technologies to facilitate their scrolling and/or editing of
>   content. Highly effective assistive technologies exist to accomodate
>   alternative input strategies ranging from:
>     * speech input technology, such as [9]DragonDictate or
>       [10]NaturallySpeaking;
>     * mouse and keyboard alternative systems, such as the [11]GNOME
>       On-Screen Keyboard (GOK), [12]Jambu, which provides improved web
>       accessibility for switch and alternative pointer users, and
>       [13]OpenEyes, an open-source open-hardware toolkit for real-time
>       eye-tracking;
>     * context-aware word-prediction technologies, such as [14]Dasher
>   Users of alternative input assistive technologies require two specific
>   accomodations for scrolling and editing domain specific content:
>    1. Context aware expedited scrolling and navigation. The Navigation
>       Use Cases outlined in this document will serve this requirement.
>    2. Knowledge domain context aware command and content vocabulary for
>       speech based navigation systems and for word-prediction systems.
>     _________________________________________________________________
>  Navigability Use Cases
>   AT users need to be able to navigate within sub-components of
>   documents containing specialized content, such as math, music or
>   chemical markup. Typically these specialized components have content
>   which needs to receive "focus" at different levels of granularity,
>   e.g. a numerator within a numerator, an expression, a term, a bar of
>   music, etc.
>   Within each level, functions are needed in response to AT commands to
>   inspect and navigate to and from "items" (e.g., by word, bar,
>   expression, clause, term, depending upon the type of content being
>   expressed) for a particular level of granularity:
>    1. contextual query/inspection of object/glyph with current focus
>       ("[15]Where Am I?")
>    2. character-by-character
>    3. previous/current/next item
>    4. all items with user-defined characteristics
>    5. all items in a author-defined category ([16]footnote 1)
>    6. first/last item on a line
>    7. first/last item within next higher or lower level of granularity
>    8. first/last item in the document
>   There are two scenarios to consider, a read-only scenario and a
>   scenario where the user is editing the document.
>   There are three system components that need to interact: the user
>   agent, e.g. a browser, the AT, and the expert handler.
>   In the read-only case, the AT responds to some sort of "Point of
>   Regard" change event and depending on the "role" of the object which
>   received focus, the AT fetches accessibility information pertinent to
>   that role and then formats/outputs a response tailored to an AT user,
>   e.g. TTS/braille. In the case of specialized content, an expert
>   handler needs to be used by the AT because the AT doesn't know how to
>   deal with such specialized content directly.
>   In order to meaningfully interact with the specialized content, the
>   user needs to be able to execute the following actions:
>     * change level of granularity up/down
>     * read all from top
>     * read all from Point of Regard (POR)
>     * goto and read first/last item on the current line
>     * goto and read first/last item within the next less/more granular
>       item
>     * goto and read first/last item in the document
>     * goto and read previous/current/next item
>   In the case of editable content there may also be a desire to have
>   separate cursors, e.g. one to remain at the POR (the caret, if
>   editing), and one to move around for review purposes.
>   The AT will already have UI input commands for most of the above
>   functions, but probably not for changing to higher/lower levels of
>   granularity. If the AT needs to provide the user with an increased
>   level of granularity, in response, the AT would call the handler to
>   change the mode of granularity. The AT will handle the UI commands and
>   in turn call the handler to return an item at the current level of
>   granularity. The AT would have told the handler about the output mode,
>   e.g. braille or TTS. Armed with those three things: level of
>   granularity, mode of output, and which item (first, last, previous,
>   current, next), the handler knows what to do.
>   In the case of editable content, the UA provides the input UI for the
>   user. This editing capability would most likely be provided via a
>   plugin. An example of such a plugin is needed so that one can evaluate
>   what accessibility features need to be added to the existing editors.
>     _________________________________________________________________
>  Magnification Use Cases
>   A common use of magnification is to proportionately enlarge content.
>   For text-based (or more generally, font-based) applications, this
>   means that AT software should be able to request rendering with larger
>   sized fonts or a certain amount of magnification relative to some
>   baseline magnification. Applications beyond standard text-based ones
>   include math, music, and labeled plots/graphics. For non text-based
>   applications such as graphics and chemical structures, magnification
>   could be based on a certain percentage of the normal size or given by
>   "fill this area". These two ideas can always be mapped onto each
>   other. In all of these cases, the magnification may be due to having
>   the entire documented magnified or it may be due to a request to
>   magnify an individual instance (such as an equation).
>   There are two other uses for magnification:
>    1. While navigating or speaking, it might be desirable to magnify the
>       part being navigated/spoken to make it easier to see. For example,
>       while playing some music, the current measure and next measure
>       might be magnified to ease reading while leaving the rest
>       unmagnified so that the amount of screen space used is minimized.
>       There also needs to be a method to reset the magnification.
>    2. Math and Chemical notation shrink fonts for superscripts and
>       subscripts. In math, these are further reduced for nested scripts.
>       One common feature for math renderers is to set a minimum font
>       size. Typically, this is 50% of the base font size and corresponds
>       to the size used for doubly nested scripts. It is potentially
>       useful to allow the AT to control the maximum percent shrinkage
>       used by renderers. Another possibility is to have a feature that
>       says "don't shrink at all". Although the rendering would not be
>       consider high quality typesetting, it does make scripts more
>       readable to those with some vision impairment.
>     _________________________________________________________________
>  Braille Display, Embossing and Tactile Conversion Use Cases
>   An Expert Handler should be able to provide braille data for braille
>   display output by generic AT. Custom braille output is needed, because
>   generic AT has no knowledge about how specific specialized data can
>   and should be represented via braille. An example is mathematics:
>   there are many different braille codes used to represent mathematics
>   that vary from country to country and agency to agency, which affects
>   how [17]MathML is translated into a tactile form.
>   Simple ASCII strings are normally used to communicate braille to
>   braille devices. However, there are a lot of specific ASCII-to-dots
>   pattern-encoding tables used to generate braille that conforms to a
>   natural language's braille conventions. Therefore AT and expert
>   handler have to negotiate braille table to be used. A more universal
>   approach would be use special braille Unicode symbols in range from
>   0x2800 to 0x28FF.
>   There is also a need to have braille output tailored to various level
>   of granularity. For example, at a low level of granularity, the user
>   would receive an overall description of the mathematical expression or
>   image, while at the highest level of granularity, the user would
>   receive a complete braille translation of the whole math expression or
>   list of all labeled components of the image.
>   Some data may need to be expressed in a more advanced tactile output
>   format than refreshable braille. For example, graphical data would
>   greatly benefit from being embossed on paper or a 2D braille display.
>   Input devices, such as a touchpad or camera, which allow a user to
>   communicate to the computer which parts of the graphic the user is
>   interested in and needs to be tactilely displayed. Such interactive
>   functionality should be left exclusively to the expert handler. This
>   means that an expert handler must have an interactive mode and a way
>   for an AT to trigger/toggle this mode on. In such a mode, an AT should
>   also provide a way for the expert handler to produce more than one
>   output stream -- such as simultaneous speech and braille output --
>   directly via an AT device which uses the same TTS engine and/or
>   braille display.
>     _________________________________________________________________
>  Universal Use Cases
>  Universal Use Case 1: Where Am I?
>   The user must have a means of obtaining all available information
>   about the object/character with focus, beginning with the repetition
>   of the character or the programmatic binding which describes the
>   object with focus. The ability to query the AT to determine one's
>   point of regard within a document and within containers in the
>   document is essential. The user must be able to obtain information
>   about the current point of regard at from most generic level -- what
>   percentage of the document or section has been read, how much of the
>   document or section remains to be read -- to the most atomic.
>   Therefore, an AT must create a User Interface where successive "Where
>   Am I?" queries by the user generate more verbose or more terse
>   responses. ([18]footnote 2)
>  Universal Use Case 2: Document Summary
>   A user may find it necessary to consult a "Document Summary",
>   containing a list of the types of elements and containers in the
>   document. The user needs to know the document title and language as
>   well as the number of tables, links, headings, frames, forms,
>   controls, items, images, and pages. The application may implement a
>   document summary feature natively through its own UI instead of an
>   accessibility API, but in the case of specialized markup, may need the
>   assistance of an expert handler in order to present an appropriate
>   document summary for the content being summarized.
>     _________________________________________________________________
>  Putting It All Together: Expert Handlers and the Flow of Control
>   The goal of the [19]Expert Handlers working group is to define a
>   standard so that AT software can call on expert software to interpret
>   specialized markup. One issue that needs to be addressed is how and
>   where (in the flow of control of reading a page) should the expert
>   handler get invoked. Here are three possibilities:
>     * During installation, the expert handler registers itself with the
>       rendering application (e.g., the web browser, PDF viewer, etc.).
>       When the page is loaded, the handler is invoked by the renderer to
>       convert the DOM or some proxy for the DOM node to make it appear
>       to have non-expert content. For example, it might convert the
>       specialized markup to text or some generalized markup that AT can
>       typically handle.
>     * The AT traverses the DOM and when it gets to some node it doesn't
>       understand, it consults some resource that associates a particular
>       handler with the node name. It gets the node's content (which
>       might include other nodes) from the DOM and passes that content to
>       the expert handler. It then issues requests to the handler (e.g.,
>       "give me text to speak for the content").
>     * The AT traverses the DOM and when it gets to some node it doesn't
>       understand, it consults some resource that associates a particular
>       handler with the node name. It then points the expert handler to
>       that node and issues requests to the handler. In this case, the
>       handler is directly interacting with the DOM.
>   Although similar, the later two cases probably have implications on
>   the difficulty of implementation and the capabilities of the
>   interface. Some of these are:
>     * If the expert handler directly reads the DOM, then the expert
>       handler must understand MSAA, [20]IA2, or whatever is appropriate
>       for the level of functionality it needs. This also implies that
>       the rendering application must support those standards. If not,
>       the expert handler would need to know how to access application
>       specific DOMs.
>     * If the expert handler is given a copy of what resides in the DOM,
>       then interacting with the content (e.g., filling in a text field)
>       would complicate any standard that is developed because support
>       for passing info about input would need to be part of the
>       standard.
>     _________________________________________________________________
>  Footnotes
>   Note 1. for example, the FIELDSET, LEGEND, LABEL grouping and
>   labelling mechanisms for FORM controls or the headers/id relationship
>   defined for TABLE in [21]HTML 4.01/[22]XHTML 1.0 or the [23]ARIA
>   markup "[24]labelledby " and "[25]describedby"
>     * [26]return to the text following note 1
>   Note 2. For each potential point of regard possible in a specific
>   Generalized Markup Language, the AT requires, and can usually obtain
>   from the document's structure and semantics, as reflected in the DOM,
>   the following element characteristics, if they exist, depending on the
>   type of elements in the item at the current POR:
>     * For all locations:
>         1. Number of items in the document
>         2. Relative item number (n of total) within the document
>         3. Document title
>     * Table information if in a table:
>         1. Caption and table summary
>         2. Content for row and column headers
>         3. Relative number (n of total number) for the table in the
>            document
>         4. Relative row and column number (x of total, y of total)
>            within parent table
>         5. Table type/role (data, spreadsheet, calendar)
>     * Section information if in a section:
>         1. Section type (page, frame, heading)
>         2. Section title
>         3. Relative number (n of total) for the section type in the
>            document
>         4. Level if in a section with a heading
>         5. Relative item number (n of total) within the section
>     * Form control information if on a form control:
>         1. Group label for a control (such as LEGEND or OPTGROUP in
>            HTML) if in a group
>         2. Label or alternative text (such as title or alt in HTML or
>            title and desc in SVG)
>         3. Type of form control (role)
>         4. State
>         5. Relative number (n of total) of the parent form in the
>            document
>         6. Relative form control number (n of total) within the parent
>            form
>     * Map information if in a map:
>         1. Relative area number (n of total) within the areas of a map
>         2. Title attribute for map
>     * List or menu information if within a menu or list:
>         1. Type (role) - menu, simple list, definition list, ordered
>            list, folder, navigation bar, and so on
>         2. Title from parent menu or list
>         3. Relative number (n of total) of parent list or menu in the
>            document
>         4. Relative list item number (n of total) within the list
>     * Link information if on a link:
>         1. Relative link number (n of total) within the document
>         2. Link state: visited, unvisited, active, focused, external or
>            internal
>         3. Extended information, such as that provided by the title
>            attribute
>   For [27]Specialized MarkUp Languages, the above list of points of
>   regard needs to be broadened and abstracted into a context meaningful
>   to the content and structure achieved through the use of a particular
>   specialized markup language. For example, a musical score marked up in
>   an XML-derived dialect, would frame its points of reference in a manner
>   conformant with the structure of the content being accessed: by stanza,
>   by bar, by note, and so on. The level of granularity necessary to
>   provide meaningful interaction between the user of an AT and a specific
>   markup language is highly dependent upon the type of specialized
>   content being described, as well as the parameters and structures
>   inherent to the specialized knowledge domain for which the specialized
>   markup language has been designed. Expert handlers, therefore, need the
>   ability to cache ontologies specific to each type of specialized
>   content, in order to enable full interactivity with the specialized
>   content. Such ontologies can be provided through either the [29]Web
>   Ontology Language (OWL) or the [30]Resource Description Framework (RDF)
>   in order to provide an assistive technology with meaningful, and
>   appropriately structured, API calls and mappings.
>     * [31]return to the text following note 2
>     _________________________________________________________________
> References
>   1.
> http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/Unifie=
>   2.
> http://www.linux-foundation.org/en/Accessibility/Handlers/References/GMLs=
>   3.
> http://www.linux-foundation.org/en/Accessibility/Handlers/References/SMLs=
>   4.
> http://www.linux-foundation.org/en/Accessibility/Handlers/References/SMLs=
>   5.
> http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/Unifie=
>   6.
> http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/Unifie=
>   7.
> http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/Unifie=
>   8.
> http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/Unifie=
>   9. http://www.ddwin.com/dictate.htm
>  10. http://www.ddwin.com/deluxe.htm
>  11. http://www.gok.ca/
>  12. http://www.oatsoft.org/trac/jambu
>  13. http://www.oatsoft.org/Software/open-eyes
>  14. http://www.inference.phy.cam.ac.uk/dasher/
>  15.
> http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/Unifie=
>  16.
> http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/Unifie=
>  17.
> http://www.linux-foundation.org/en/Accessibility/Handlers/References/SMLs=
>  18.
> http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/Unifie=
>  19. http://www.linux-foundation.org/en/Accessibility/Handlers
>  20. http://www.linux-foundation.org/en/Accessibility/IAccessible2
>  21. http://www.w3.org/TR/html401
>  22. http://www.w3.org/TR/xhtml10/
>  23. http://www.w3.org/TR/aria-roadmap
>  24. http://www.w3.org/TR/aria-roles/#labelledby
> <!-- change to: http://www.w3.org/TR/wai-aria/#labelledby when goes "live"
> -->
>  25. http://www.w3.org/TR/aria-roles/#describedby
> <!-- change to: http://www.w3.org/TR/wai-aria/#describedby when goes
> "live" -->
>  26.
> http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/Unifie=
>  27.
> http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/Unifie=
>  28. http://www.w3.org/TR/owl-ref/
>  29. http://www.w3.org/TR/REC-rdf-syntax/
> <!-- should link 29 link to the RDF spec or the RDF activity at
> http://www.w3.org/RDF -->
>  30.
> http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/Unifie=
> _______________________________________________
> Accessibility-handlers mailing list
> Accessibility-handlers at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/accessibility-handlers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/accessibility-handlers/att=

More information about the Accessibility-handlers mailing list