w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire Design of ACT Rules Pages
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: shadi+ACTsurvey@w3.org
This questionnaire was open from 2020-11-03 to 2020-11-19.
4 answers have been received.
Jump to results for question:
1. Example of ACT Rule
summary | by responder | by choice
Please review Example of ACT Rule. Consider the following aspects from the perspective of external users of this resource (ie. not Task Force and Working Group participants):
- Review the order of sections, including their reading order in the code.
- Review the page and section titles, including presentation and styling.
- Review the navigation within the page and across the entire resource
- Review which (sub-)sections should and should not be collapsible.
- Review the one-sentence description in "About this Page" section.
- Review the meta-data presented in "About this Page" section.
- Review the meta-data/summary presented at the top of the page.
Please select from the following:
Summary
| Choice | All responders |
|---|---|
| Results | |
| I agree with the page design as proposed (no changes suggested) | |
| I agree with the proposed page design but have comments; please provide your suggestions as GitHub issues or in the text box below | 3 |
| I do not agree with the proposed page design; please provide your reasons as GitHub issues or in the text box below | 1 |
| I abstain from commenting on this proposed page design (you don't feel strongly either way) |
Skip to view by choice.
View by responder
Details
| Responder | Example of ACT Rule | Comments |
|---|---|---|
| Wilco Fiers |
|
- I don't think the requirements mapping is in the right place. In my opinion it belongs above the description. We could collapse it down. We did that in the rules pages in the ACT website. - I'm not too keen on collapsing all the examples and definitions. The CG has been working to make the definitions shorter, we done part of this already, and have some more ideas for it. As for collapsing examples, if we're going to do that, I'd prefer we show the first two examples of each type and collapse the rest under a "show more example" button of some sort. I think the examples are important, so I don't think they should be hidden, at least not in its entirety. - These pages need better code highlighting. Code is much easier to read with highlighting enabled. |
| Trevor Bostic |
|
A lot of these comments were made during the meeting but I will add them here for full documentation. 1. I think we should consider a small divider between the "Test Rule" text at the top and the rule title. 2. Move requirements mapping above applicability? 3. Code should be visually divided a little more, code syntax highlighting would be nice, and make sure that whitespace is correct on nested tags. 4. For each test case, add a link to page with example of the provided code. |
| Kathy Eng |
|
- I think users would like the test cases to be working examples (like we currently have), especially for manual testing. - the H2 anchor links should not have aria-hidden="true". Keyboard focus just shows an outline, but not the svg. - Can the code in the Examples have some different style so it's more distinct from the text? - "whitespace" in Expectation 2 links to the glossary definition, but "Outcome" in Accessibility Requirements Mapping does not. - Not entirely sure this is true: Accessibility Conformance Testing (ACT) Rules describe ways to test conformance to WCAG success criteria. I think ACT Rules describe expectations of WCAG success criteria and are designed to check for failures in satisfying WCAG success criteria. "Ways to test" is automated/manual in my mind. - it's stated 3 times that this is an atomic rule. Perhaps the section at the top (immediately below the Rule title) is not needed. Providing the SC isn't necessary at the top either since it is provided under Accessibility Requirements Mapping.) |
| Mary Jo Mueller |
|
I do think the requirements mapping should go higher, but right after the rule description. To me the rule description is typically very brief and then you can read it to understand what the rule is testing. Then see in the next section how it is mapped to the requirements. I like to understand what the rule is before reading what it applies to. Agree that code examples should have two parts 1) show the code (with a special code visual treatment), and 2) as a link to something where it is working so someone could verify their tool or manual test methodology against it. Issues in the callout box: DOM tree is a non-working link. The tooltip for the rule type should use text that is closer to what is in the ACT Rules Format specification. |
View by choice
| Choice | Responders |
|---|---|
| I agree with the page design as proposed (no changes suggested) | |
| I agree with the proposed page design but have comments; please provide your suggestions as GitHub issues or in the text box below |
|
| I do not agree with the proposed page design; please provide your reasons as GitHub issues or in the text box below |
|
| I abstain from commenting on this proposed page design (you don't feel strongly either way) |
2. All ACT Rules
summary | by responder | by choice
Please review All ACT Rules. Consider the following aspects from the perspective of external users of this resource (ie. not Task Force and Working Group participants):
- Review the page and section titles, including presentation and styling.
- Review the navigation within the page and across the entire resource
- Review the short description in the "Summary" section.
Please select from the following:
Summary
| Choice | All responders |
|---|---|
| Results | |
| I agree with the page design as proposed (no changes suggested) | 1 |
| I agree with the proposed page design but have comments; please provide your suggestions as GitHub issues or in the text box below | 1 |
| I do not agree with the proposed page design; please provide your reasons as GitHub issues or in the text box below | 2 |
| I abstain from commenting on this proposed page design (you don't feel strongly either way) |
Skip to view by choice.
View by responder
Details
| Responder | All ACT Rules | Comments |
|---|---|---|
| Wilco Fiers |
|
|
| Trevor Bostic |
|
I am a little worried about how this will be organized as the rule list grows. I am not immediately sure what the best way of group them is (alphabetically, by success criteria, etc.). It may also be helpful to eventually add a search text box. |
| Kathy Eng |
|
- how will the list of rules be organized so users can find what they're looking for when this list is long? Could it be by SC that has a collapsible list of rules? Or a sortable table with SC | Date added as col headers. - Not entirely sure this is true: Accessibility Conformance Testing (ACT) Rules describe ways to test conformance to WCAG success criteria. I think ACT Rules describe expectations of WCAG success criteria and are designed to check for failures in satisfying WCAG success criteria. "Ways to test" is automated/manual in my mind. |
| Mary Jo Mueller |
|
IMO, there will eventually be a much longer list of rules, as well as composite and related atomic rules, so a list hierarchy could be used to show that relationship. Initially, an alphabetic listing could be used but as the list grows, a table showing each WCAG SC with its associated rules could be easier to digest (with rules repeated in the table if they are used for multiple SC). Not sure how fancy to get with this, as we will be incorporating the rules into the related WCAG 2.2 materials for each of the SC. It might also be helpful to have the publication date available in the list so someone can browse the list to see what's new without having to open each rule to find out. |
View by choice
| Choice | Responders |
|---|---|
| I agree with the page design as proposed (no changes suggested) |
|
| I agree with the proposed page design but have comments; please provide your suggestions as GitHub issues or in the text box below |
|
| I do not agree with the proposed page design; please provide your reasons as GitHub issues or in the text box below |
|
| I abstain from commenting on this proposed page design (you don't feel strongly either way) |
3. About ACT Rules
summary | by responder | by choice
Please review About ACT Rules. Consider the following aspects from the perspective of external users of this resource (ie. not Task Force and Working Group participants):
- Review the order of sections, including their reading order in the code.
- Review the page and section titles, including presentation and styling.
- Review the navigation within the page and across the entire resource
- Review which (sub-)sections should and should not be collapsible.
- Review the main description in the "About ACT Rules" section.
Please select from the following:
Summary
| Choice | All responders |
|---|---|
| Results | |
| I agree with the page design as proposed (no changes suggested) | |
| I agree with the proposed page design but have comments; please provide your suggestions as GitHub issues or in the text box below | 4 |
| I do not agree with the proposed page design; please provide your reasons as GitHub issues or in the text box below | |
| I abstain from commenting on this proposed page design (you don't feel strongly either way) |
Skip to view by choice.
View by responder
Details
| Responder | About ACT Rules | Comments |
|---|---|---|
| Wilco Fiers |
|
- Don't think we should mention "cover more current best practices". None of the rules currently published test best practices, nor do we have any plans to do so. - I don't understand what the second to last paragraph is for. (The one that starts "This set of ACT Rules is not intended to be used as a stand-alone resource"). The quickref is a good tool for development, but not nearly as useful for methodology developers IMO. There normative language is what counts. |
| Trevor Bostic |
|
I don't know exactly what the expected contents of change log and acknowledgements will be, but I am unsure if they will need to be collapsible. I could see it eventually happening for the changelog if it gets very long. |
| Kathy Eng |
|
- 2nd paragraph: Remove "best" from "This set of ACT Rules is updated periodically to cover more current *best* practices..." - 4th paragraph: Remove "usually" from "it is expected that developers of automated testing tools and manual testing methodologies will *usually* use How to Meet WCAG 2.1: A customizable quick reference..." - not sure a Change Log is necessary, but don't feel strongly |
| Mary Jo Mueller |
|
IMO, the 2nd paragraph doesn't accurately characterize the status of the ACT rules. These are published rules that have been approved by the AG WG to be tests for WCAG conformance. However, the list of tests is not comprehensive, as quite a number of rules are in development and will be published after a rigorous review process. Since this is not a normative resource, I don't think a change log is necessary. Content seems to be in the right order, and I don't have any comments on styling. |
View by choice
| Choice | Responders |
|---|---|
| I agree with the page design as proposed (no changes suggested) | |
| I agree with the proposed page design but have comments; please provide your suggestions as GitHub issues or in the text box below |
|
| I do not agree with the proposed page design; please provide your reasons as GitHub issues or in the text box below | |
| I abstain from commenting on this proposed page design (you don't feel strongly either way) |
More details on responses
- Wilco Fiers: last responded on 16, November 2020 at 12:49 (UTC)
- Trevor Bostic: last responded on 17, November 2020 at 18:53 (UTC)
- Kathy Eng: last responded on 18, November 2020 at 00:40 (UTC)
- Mary Jo Mueller: last responded on 18, November 2020 at 22:57 (UTC)
Non-responders
The following persons have not answered the questionnaire:
- Katie Haritos-Shea
- David MacDonald
- Romain Deltour
- Detlev Fischer
- Chris Loiselle
- Jonathan Avila
- Rachael Bradley Montgomery
- Charles Adams
- Daniel Montalvo
- Todd Libby
- Thomas Brunet
- Catherine Droege
- Suji Sreerama
- Shane Dittmar
- Nayan Padrai
Send an email to all the non-responders.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project