Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Section “13. Accessibility Support” unclear #221

Closed
nitedog opened this issue Jul 5, 2018 · 2 comments · Fixed by #283
Closed

Section “13. Accessibility Support” unclear #221

nitedog opened this issue Jul 5, 2018 · 2 comments · Fixed by #283

Comments

@nitedog
Copy link
Contributor

nitedog commented Jul 5, 2018

From Stefan Schnabel:

Section “13. Accessibility Support”:

“Because of this, ACT Rules are not necessarily applicable in all test scenarios. For instance, a web page that has to work in assistive technologies that have no WAI-ARIA [WAI-ARIA] support, wouldn’t be tested with an ACT Rule that relies on WAI-ARIA support, since this could lead to false positive results.”

This is not understandable without further examples or rewording especially what “false positive results” would mean.

Concealment does not improve things.

I mean, shouldn’t the rule set actively encourage the USE of WAI-ARIA instead of doing protectionism for older AT and user agents?

Of course, respective rule messaging should be flagged accordingly.

@WilcoFiers
Copy link
Collaborator

I've made some minor tweaks to it. One of the goals of the rules format was to allow rule designers to express limitations on accessibility support. Website owners are free to choose if they wish to push their users to the most modern assistive technologies out there, or if they wish to hold up some degree of backward compatibility. Rules should not be limiting in that respect.

@nitedog
Copy link
Contributor Author

nitedog commented Sep 21, 2018

@WilcoFiers I do not think your edits help remove the negativity. In fact, the sentence now has a jarring double negation that makes it difficult for me to understand it.

More importantly, I do not understand what requirements this section sets and what to include in it. It is also a confusing mix of things that relate to rule authors and rule implementations.

Below is a suggested attempt to rewrite that section, to hopefully make it clearer. I believe it does not change any of the meanings but separates out the different thoughts:

[[
Content can be designed to rely on the support for particular accessibility features by different assistive technologies and user agents. For example, content using a particular WAI-ARIA [[WAI-ARIA]] feature relies on that feature to be supported by assistive technologies and user agents. This content would not work for assistive technologies and user agents that do not support WAI-ARIA. WCAG [[WCAG]] provides a definition for accessibility supported use of a Web technology.

ACT Rules, including [=composite rule=] and [=atomic rules=], MUST specify known limitations on accessibility support. For example, an atomic rule that checks for a particular accessibility feature that is known to be not widely supported by assistive technologies and web browsers, or a composite rule that includes atomic rules with known accessibility support limitations.

Implementations of ACT Rules SHOULD convey corresponding notifications to their users when results from rules with known accessibility support limitations are conveyed.

NOTE: WCAG Evaluation Methodology (WCAG-EM) provides guidance on defining an accessibility support baseline for test scenarios, which can help users of ACT Rules to select the appropriate rules for their own circumstance.
]]

WilcoFiers added a commit that referenced this issue Sep 24, 2018
* Remove aspects MUST requirement #264

* Updated aspects based on feedback #257

* Make test cases required for all rules

* Change "local laws" to "laws" #231

* Add a paragraph on accessibility of rules #226

* Rewrote benchmark to non-normative section #236 #239 #163

* Consistency in rule-aggregation #266

* Tweaked accessibility support language #221

* Changed test subject from MUST to MAY #220

* Require rule IDs in atomic rules list #261

* Fix rule type example #230

* Add rule type to the rule structure #232

* Update from #274

* Add "satify" explanation for Rules to SCs. #227

* Example to "satisfy" WCAG SCs #250

* Scrub document to ensure correct use of "should" and "may" #267

* Break up the PR
@WilcoFiers WilcoFiers mentioned this issue Oct 11, 2018
WilcoFiers added a commit that referenced this issue Oct 14, 2018
### Issues resolved by this PR: 

- Clear split between requirements for rule authors vs. rule implementers : Closes #272
- Need a definition of Test Target : Closes #271
- 16. Rule Aggregation - Add Requirement : Closes #252
- Accessibility Requirements: Updates requested (Shadi) : Closes #250
- 15.2. Accuracy Benchmarking - Update definition : Closes #236
- Outcomes of atomic tests : Closes #235
- clarifying the relationship between rule application and accessibility conformance : Closes #227
- ACT i18n checks : Closes #226
- Clarify the definition of Rule Aggregation : Closes #165
- Clarify how to do "Implementation validation" and "accuracy benchmarking" for manual or semi-automated rules : Closes #163
- Clarify the output format definition : Closes #162
- Mark all Informative sections as such : Closes #280
- "Failed" / "Passed" or "Fail"/"Pass"? : Closes #279
- Require Rule ID's in Atomic Rule List : Closes #261
- Scope sections states ACT rules should not be used for conformance : Closes #281
- Section “13. Accessibility Support” unclear : Closes #221
- Examples need to be identified accessibly : Closes #187

### Outstanding discussions before CR: 

- List of features for exit criteria #224

### Outstanding editorials before CR:

- Need non-versioned biblio reference tags #216


<!--
    This comment and the below content is programatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/w3c/wcag-act/pull/283.html" title="Last updated on Oct 12, 2018, 12:04 PM GMT (1776294)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/wcag-act/283/38370ea...1776294.html" title="Last updated on Oct 12, 2018, 12:04 PM GMT (1776294)">Diff</a>
@nitedog nitedog added For CR and removed For CR labels Mar 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants