W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2001

Representing UAAG 1.0/Section 508 relationships in RDF

From: Ian B. Jacobs <ij@w3.org>
Date: Tue, 18 Dec 2001 14:17:45 -0500
Message-ID: <3C1F9659.D8C97BE7@w3.org>
To: w3c-semweb-ad@w3.org, w3c-wai-ua@w3.org
Dear Semantic Web Advance Developers and
     User Agent Accessibility Guidelines Working Group,

NOTE: I have sent this email to two mailing lists, w3c-semweb-ad
is Member-confidential and w3c-wai-ua is public. If possible, I
would like for this discussion to go on on the public UAWG
mailing list.

On 14 December, Eric Miller and I started thinking about how to
represent in RDF relationships between the accessibility
requirements of W3C's UAAG 1.0 [1] and those of section 508
[2]. The User Agent Accessibility Guidelines Working Group (UAWG)
would like to have a resource to show developers how the
documents relate. Some of the UAWG participants began to write up
relationships in HTML [3], but this seems like a great RDF
application from which we could (1) generate multiple views (2)
do some automation, for example in the area of test suites and
evaluations. I am primarily interested today in different views
of the relationships.

While RDF seems to be the obvious choice for representing these
relationships, what I have found by comparing the two documents
is that the relationships are very fuzzy. Rare are the
requirements one could really call equivalent. And it is even
rare that one neatly subsumes another. The most comment
relationship seems to be "overlaps", and it would be good to be
able to add information to explain where two requirements do and
don't overlap.

This is my first foray into Semantic Web work, so I hope that the
Semantic Web Advance Development (SWAD) folks will take this
opportunity to educate not just me but all those on the UAWG
mailing list. In particular, I look forward to your comments on
 
  a) How to represent these relationships in RDF.
  b) How to represent what seem to be fuzzy relationships. You
     probably have experience with vocabularies that may do
     some of what we are trying to do.

Furthermore, Charles has pointed out that we should be thinking
of EARL [4] at the same time. For instance, if we write down in
EARL that a user agent U satisfies 10 requirements in UAAG 1.0
and in turn we have written down in RDF that satisfying those 10
requirements implies satisfaction of 12 section 508 requirements,
machines will be able to deduce that U also satisfies section 508
requirements. Refer to the implementation reports of UAWG [5],
not yet in EARL but we hope to migrate to EARL soon.

Below are some suggested attributes and relationships.
Your comments are very welcome!

 - Ian

----------
ATTRIBUTES
----------

- Priority. UAAG 1.0 checkpoints are prioritized
   (1,2,3) and section 508 checkpoints are not, so by default,
   all 508 checkpoints should be considered priority 1. When
   comparing two requirements, they may be the same technically,
   but have different priorities and thus need to be distinguished.

- Content v. User Interface. 
   Both documents distinguish content and user interface. 
   For example, from 508, Subpart B, 1194.21:

    (k) Software shall not use flashing or blinking text,
    objects, or other elements having a flash or blink frequency
    greater than 2 Hz and lower than 55 Hz.

   In UAAG 1.0, checkpoint 3.3:

    1.Allow configuration to render animated or blinking text as
    motionless, unblinking text.

   Comment: In UAAG 1.0, the control is only required for
   content. In 508, presumably the requirement is for both
   content and UI (though not entirely clear). In conjunction
   with an "Overlaps" relationship, one could learn that the
   two requirements differ along the content/UI axis.

- Output modality. UAAG 1.0 identifies three output modalities:
  visual, audio, braille. UAAG 1.0 doesn't include any braille
  requirements. Section 508 includes primarily visual
  requirements. Two requirements might be the same except that the
  UAAG 1.0 also applies to audio output (e.g., focus
  highlight). Thus, the requirements need to be distinguished along
  this axis.

- Topic. I would like to be able to suggest some categories for
  grouping relationships. These categories would be based on the
  table of contents of either UAAG 1.0 or section 508, for
  example. Should this be an attribute or more RDF that you layer
  on top of the requirement relationships?

-------------
RELATIONSHIPS
-------------

- 'overlaps'. In most cases, the requirements of the two documents
  are very similar, and overlap in some way. It would be useful
  to be able to indicate where two requirements overlap and
  where they don't. For example, from 508, Subpart B, 1194.21:

     (a) When software is designed to run on a system that has a
     keyboard, product functions shall be executable from a
     keyboard where the function itself or the result of
     performing a function can be discerned textually.

   UAAG 1.0, checkpoint 1.1:

     1.Ensure that the user can operate through keyboard input
     alone any user agent functionality available through the
     user interface.

   Comment: Both requirements involve the keyboard. Both
   requirements carve out exceptions (508 exceptions:
   it doesn't apply when software not designed for keyboard
   or when function cannot be discerned textually. UAAG 1.0
   exceptions: doesn't apply if not available through the UI).
   The exception cases are different, so the requirements are
   not equivalent, and one does not strictly subsume the other.

- equivalence relationships. There are few cases of real
  equivalence between UAAG 1.0 and section 508. [There are 
  equivalent requirements in WCAG 1.0 and the Web content
  part of section 508 since there was greater coordination.]
  There are shades of equivalence, but I'm not sure how to 
  represent those shade, nor do I have concrete
  criteria for picking one shade over another. For instance,
  we might have 'nearlyEquivalentTo'.

   From 508, Subpart B, 1194.21:
  
      (b) Applications also shall not disrupt or disable
      activated features of any operating system that are
      identified as accessibility features where the application
      programming interface for those accessibility features has
      been documented by the manufacturer of the operating system
      and is available to the product developer.

   UAAG 1.0, checkpoint 7.2 

      1. Ensure that default input configurations do not
      interfere with operating environment accessibility
      conventions.

   Comment: There is an exception carved out for 508 (when API
   not documented, don't need to do this), but these
   requirements are nearly equivalent.

   Another example: 508 d.1 and UAAG 1.0, 6.4.1

   Another example: 508 c.1 and UAAG 1.0, 10.6. However, UAAG
   1.0 is more than visual highlighting. 
   See "output modality" attribute.

- 'partOf'. N requirements together from document A may comprise
   a single requirement of document B. Note: since we are
   interested in sentence level comparisons (refer to note on
   references below), "partOf" means that the requirement made
   by a given sentence is part of a requirement made in the
   other document. 

   Example: 508 c.2 is met by UAAG 1.0, 9.1.1 + 9.2.1 + 6.5.1
            
- 'seeAlso'. For cross references to related requirements. Example.

   From 508:

    (e) When bitmap images are used to identify controls, status
    indicators, or other programmatic elements, the meaning
    assigned to those images shall be consistent throughout an
    application's performance.

   Comment: There is no corresponding requirement in UAAG 1.0,
   but the WG expects that related requirements will cover this
   one. For instance:

   UAAG checkpoint 7.3

     1. Follow operating environment conventions that benefit
     accessibility. In particular, follow conventions that
     benefit accessibility for user interface design, keyboard
     configuration, product installation, and documentation.

------------------------
Citing requirements
------------------------

  * For Section 508: Subpart, para, provision (e.g.,
    Subpart B, 1194.21, provision a). 

  * For UAAG 1.0: Checkpoint, provision (e.g., checkpoint 2.3,
    provision 3).

  In both cases, we would like to have sentence-level 
  comparisons.

-------------------------------------------------
[1] http://www.w3.org/TR/UAAG10/
[2] http://www.access-board.gov/sec508/508standards.htm
[3] http://www.w3.org/WAI/GL/508/508-UAAG.html
[4] http://www.w3.org/WAI/ER/#earl
[5]
http://www.w3.org/WAI/UA/implementation/report-cr2-checkpoint-summary

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Tuesday, 18 December 2001 14:17:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:32 UTC