RE: [ARIA] Proposed changes to the taxonomy (for inheritance issues)

+1


-----Original Message-----
From: Joanmarie Diggs [mailto:jdiggs@igalia.com] 
Sent: Thursday, June 25, 2015 5:01 PM
To: W3C WAI Protocols & Formats
Subject: [ARIA] Proposed changes to the taxonomy (for inheritance issues)

Hey all.

After today's meeting and the readonly-checkbox discussion, I started thinking about other widgets that might be readonly as well as required.
And I could come up with a use case for most input fields being readonly and/or required. Then I looked again at our taxonomy and the inheritance issues and frowned and started a "taxonomy" branch in which to start tackling some of them.

Branch: https://github.com/w3c/aria/tree/taxonomy

Spec: https://rawgit.com/w3c/aria/taxonomy/aria/aria.html


Current proposed changes, which I think need doing regardless of readonly and required:

1. Remove list as a superclass of menu and listbox:
   a. List lacks unique supported properties for subclasses to inherit.
   b. The definition of list is a group of *non-interactive* list items.
      (emphasis added). Both menu and listbox are interactive groups.
   c. Menu and listbox each subclass select, "a widget that allows the
      user to make selections from a set of choices." So the list/set
      nature is already present.

2. Remove directory as a superclass of tablist:
   a. Directory lacks unique supported properties for subclasses to
      inherit.
   b. The definition of directory (which is a subclass of list) is a
      list of references to members of a group, such as a static table
      of contents. A tablist is an interactive control for which authors
      SHOULD manage focus. It's not a directory.
   c. Tablist is also a subclass of composite, "a widget that may
      contain navigable descendants or owned children." That seems
      sufficient.

3. Remove input as a superclass of scrollbar and select:
   a. The other superclass of scrollbar is range. A range is a widget
      representing a range of values that can be set by the user. This
      describes scrollbar adequately.
   b. In the case of select, making a selection from a set of choices
      does not necessarily mean a widget is an input field. A menu is
      a select; not an input. Widgets which are both (e.g. listbox) can
      subclass both.
   c. At the moment, input does not have any unique supported states
      and properties to be inherited by subclasses. However that could
      change. For instance, perhaps required and/or readonly would be
      appropriate properties for all inputs. Scrollbars and some of the
      subclasses of select (like menu) cannot be readonly or required.

Please let me know what you think about the proposed changes. Thanks!
--joanie

Received on Friday, 26 June 2015 16:32:13 UTC