Accessibility support data description

act-framework.bs

@@ -54,6 +54,34 @@ Each ACT Rule MUST have a description that:
 * Explains the accessibility requirement being tested such as the WCAG Success Criterion.
 * Refers to any related information, such as the WCAG Techniques it maps to; For example WCAG 2.0, Technique H67.
 
+Accessibility Support {#structure-acc-supp}
+---------------------------------------
+
+<p class="note">Editor's Note - The ACT Taskforce acknowledges that this approach does not capture all nuances of accessibility support. We are looking for feedback on how to balance the need for organizations to solve issues with buggy or unsupported features in assistive technologies, with keeping the development cycle lean, and delivering future-proof products.</p>
+
+Determining if a web page is accessible, depends partly on the assistive technologies that are used to access it. This is known as [Accessibility Supported in WCAG 2.0][accsupp]. When testing a web page for accessibility, it is important to know which assistive technologies are to be used for this page.
+
+Because of this it is important that users of ACT Rules can determine which accessibility features are relied upon in a rule. With this information, user can determine which rules do not provide results that are in line with the accessibility support baseline set for this particular test.
+
+Developers of Accessibility Test Tools should use this information to develop a default ruleset that is sensible for their user base. Additionally, they could allow users of ATT to customize which rules are run, allowing fine grained control of the accessibility test.
+
+A list of `Relied upon accessibility features` is an optional part of ACT Rule. Not every accessibility requirement involves assistive technologies, and so certain rules will have no use for this feature. For HTML, XML and similar markup documents, the accessibility features should be described using a three part CSS selector.
+
+- Context: The context in which the element for which support is checked lives. If there is no specific context, this can be left blank.
+- Element: The name of the element that is being tested. If the element name is irrelevant, use `*`.
+- Attributes: Specific attributes that are to be tested. If there are none, this can be left blank.
+
+Example 1: Requires support for the `alt` attribute on an `img` element, existing within a link.
+
+```
+  a[ref] img[alt]
+```
+
+Example 2: Requires support for role=menuitem on any type of element, existing within an element marked up as a menu
+
+```
+  *[role=menu] *[role=menuitem]
+```
 
 ACT Input Data {#input}
 =======================
@@ -97,11 +125,6 @@ A composition is a class or component that extends other native elements or othe
 
 Example: Component properties starting with `aria-` *must* exist in the list of WAI-ARIA attributes.
 
-Accessibility Support Data {#input-acc-supp}
---------------------------------------------
-
-Editor note: This section will describe data about the accessibility support of different assistive technologies should be used by rules to produce results. Where relevant, rules must be able to take in data about supported features in assistive technologies, and adjust results accordingly.
-
 
 ACT Test Procedure {#test-proc}
 ===============================
@@ -251,3 +274,4 @@ Appendix 1: JSON-LD Context
 }
 ```
 
+[accsupp]:  https://www.w3.org/TR/WCAG20/#accessibility-supporteddef