7223 2009-08-05 17:36:32 +0000 Research when AccessibleHypertext should be exposed as it relates to ARIA. (was What to do with 4.1 Exposing Supplemental Interfaces) 2010-11-11 22:26:06 +0000 1 1 1 Unclassified ARIA Core AAM 1.0 PC Windows XP RESOLVED FIXED P1 normal --- 1 andi.snowweaver andi.snowweaver aria-ua-impl oldest_to_newest 26242 0 andi.snowweaver 2009-08-05 17:36:32 +0000 Per the 10 July UAI TF meeting, this section is supposed to be converted into a table with the current bullets as the IAccessible2 bullets. But I'm concerned that these steps are only valid for IA2. Parking the text and markup here until we determine whether this is true. 4.1. Exposing Supplemental Interfaces In general the base markup should determine what interfaces are exposed for an accessible object. However, in the following cases WAI-ARIA markup changes which interfaces should be exposed: * AccessibleValue: as discussed in Value, the value interface should be exposed for objects with an aria-valuenow property when one of the roles on the elements supports that. Because the Value interface allows values to be set, aria-valuenow is really read/write. The browser needs to set aria-valuenow if the value is changed to a valid value, and the current element is not readonly or disabled. * AccessibleTable: should be exposed for role="grid" and role="treegrid" (XXX note: not done in Mozillaknown bug) * AccessibleSelection: should be exposed when a role supports aria-multiselectable, and aria-multiselectable="true" * AccessibleHypertext: this should not be exposed if the elements descendants have been trimmed off based on the role characteristic "Children Presentational: True": o button o img o math o progressbar o separator o slider Although it is not a WAI-ARIA-specific issue, for the purposes of accessible web applications it is worth mentioning some additionally useful rules for exposing interfaces: * AccessibleAction: should at least be exposed for anything with a "click" handler, although future versions of WAI-ARIA may bring more precision to the handling of actions. Also need to support doDefaultAction in MSAA (same as action #0)this maps to a click. * AccessibleEditabletext: should be exposed for any region made editable via contenteditable or designMode <h2>Managed States</h2> <div class="section" id="managed-states_interfaces"> <h2>Exposing Supplemental Interfaces</h2> In general the base markup should determine what interfaces are exposed for an accessible object. However, in the following cases <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> markup changes which interfaces should be exposed: <table> <caption></caption> <tr> <th></th> <th></th> </table> <ul> <li>AccessibleValue: as discussed in <a href="#mapping_special_widget-value">Value</a>, the value interface should be exposed for objects with an aria-valuenow property when one of the roles on the elements supports that. Because the Value interface allows values to be set, aria-valuenow is really read/write. The browser needs to set aria-valuenow if the value is changed to a valid value, and the current element is not readonly or disabled.</li> <li>AccessibleTable: should be exposed for role="grid" and role="treegrid" (XXX note: not done in Mozilla—known bug)</li> <li>AccessibleSelection: should be exposed when a role supports aria-multiselectable, and aria-multiselectable="true"</li> <li>AccessibleHypertext: this should not be exposed if the elements descendants have been trimmed off based on the role characteristic "Children Presentational: True": <ul> <li>button</li> <li>img</li> <li>math</li> <li>progressbar</li> <li>separator</li> <li>slider</li> </ul> </li> </ul> Although it is not a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr>-specific issue, for the purposes of accessible web applications it is worth mentioning some additionally useful rules for exposing interfaces: <ul> <li>AccessibleAction: should at least be exposed for anything with a "click" handler, although future versions of <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> may bring more precision to the handling of actions. Also need to support doDefaultAction in <abbr title="Microsoft Active Accessibility">MSAA</abbr> (same as action #0)—this maps to a click.</li> <li>AccessibleEditabletext: should be exposed for any region made editable via contenteditable or designMode</li> </ul> </div> 26278 1 andi.snowweaver 2009-08-06 20:03:41 +0000 Edits from Masahiko for this section: 4.1. Exposing Supplemental Interfaces in IAccessible2 In general the base markup should determine what interfaces are exposed for an accessible object. However, in the following cases WAI-ARIA markup changes which interfaces should be exposed in IAccessible2 (For UI Automation please refer to corresponding mapping and technical specifications from the MSDN UI Automation SDK Appendix.): * AccessibleValue: as discussed in Value, the value interface should be exposed for objects with an aria-valuenow property when one of the roles on the elements supports that. Because the Value interface allows values to be set, aria-valuenow is really read/write. The browser needs to set aria-valuenow if the value is changed to a valid value, and the current element is not readonly or disabled. * AccessibleTable: should be exposed for role="grid" and role="treegrid" (XXX note: not done in Mozillaknown bug) * AccessibleSelection: should be exposed when a role supports aria-multiselectable, and aria-multiselectable="true" * AccessibleHypertext: this should not be exposed if the elements descendants have been trimmed off based on the role characteristic "Children Presentational: True": o button o img o math o progressbar o separator o slider Although it is not a WAI-ARIA-specific issue, for the purposes of accessible web applications it is worth mentioning some additionally useful rules for exposing interfaces: * AccessibleAction: should at least be exposed for anything with a "click" handler, although future versions of WAI-ARIA may bring more precision to the handling of actions. Also need to support doDefaultAction in MSAA (same as action #0)this maps to a click. * AccessibleEditabletext: should be exposed for any region made editable via contenteditable or designMode 26289 2 andi.snowweaver 2009-08-07 11:28:22 +0000 Also this sentence that talks about considerations for AccessibleHypertext when descendant trimming occurs. "When descendant trimming occurs, the AccessibleHypertext interface should also not be exposed for the root object that remains." 27258 3 andi.snowweaver 2009-09-17 17:44:06 +0000 > * AccessibleTable: Added to Role mapping table in 3.4 >* AccessibleSelection: Already in the State/Property Mapping table in 3.5 >* AccessibleValue: Now covered in the mapping table and the Widget Values section >* AccessibleAction: Already covered in 3.7 Actions >* AccessibleEditabletext: Not related to ARIA >* AccessibleHypertext: Text only says when AccessibleHyperText should not be exposed. But when should it be exposed? 27554 4 andi.snowweaver 2009-09-22 15:25:04 +0000 David to research when AccessibleHypertext should be exposed as it relates to ARIA. 34095 5 dbolter 2010-03-29 19:21:47 +0000 IAccessibleHypertext, and GNOME AccessibleHypertext, are small sub-APIs for getting 3 things within a paragraph of hypertext: 1. getting the number of links 2. getting a specific link 3. getting the index of a specific link So the only way this intersects ARIA is for role="link". So something like blah should be included and exposed by this interface. 41815 6 andi.snowweaver 2010-10-28 15:28:00 +0000 Andi to draft text for the "link" role in the role mapping table for David to review. 42429 7 andi.snowweaver 2010-11-11 12:41:55 +0000 Added "AccessibleHypertext" to IAccessible2 column in Role Mapping table: http://www.w3.org/WAI/PF/aria-implementation/#mapping_role 42458 8 andi.snowweaver 2010-11-11 22:26:06 +0000 Per David's recommendation changed "AccessibleHypertext" to "Use IAccessibleHypertext interface".