w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: shadi@w3.org,maryjom@us.ibm.com,wilco.fiers@deque.com
This questionnaire was open from 2016-12-12 to 2016-12-14.
6 answers have been received.
Jump to results for question:
Choice | All responders |
---|---|
Results | |
I have reviewed the minutes and have no questions, they seem clear. | 5 |
I have reviewed the minutes but have questions, explained below. | 1 |
Responder | Resolutions of 14 December 2016 | Comments |
---|---|---|
Wilco Fiers | I have reviewed the minutes and have no questions, they seem clear. | |
Shadi Abou-Zahra | I have reviewed the minutes and have no questions, they seem clear. | |
Romain Deltour | I have reviewed the minutes and have no questions, they seem clear. | Wilco's link to the survey in the "Issue 7" agenda item is broken. |
Mary Jo Mueller | I have reviewed the minutes but have questions, explained below. | There was a discussion on the survey item for Action 11 on the rule description where we discussed and decided to use Shadi's suggested bulleted list which wasn't documented under item 3. |
Charu Pandhi | I have reviewed the minutes and have no questions, they seem clear. | |
Maureen Kraft | I have reviewed the minutes and have no questions, they seem clear. |
Review the following text proposed for the for the 4.1 Selectors section of the Accessibility Conformance Testing Framework Requirements document in response to Action 13: Write up on selectors 4.1. See Pull request #21: Content for the Selectors section for additional thoughts and questions Romain had on his draft content.
A selector is a boolean predicate that takes an element or component in the set represented in the input data and unambiguously tests whether the element or component matches the selector or not. In an ACT Rule, a selector is applied to the entire input data to filter it into a set of elements or components to be evaluated with the test procedure.
Selector syntax depends on the input type. When the input data is an HTML document or set of elements, the selector must be a CSS selector. When a formal selector syntax is not available for the input type, the selector may be described unambiguously in plain English.
Choose one of the following and record your comments in the github conversation tab for pull request #21: Content for the Selectors section (preferred) or in the comment box below.
Choice | All responders |
---|---|
Results | |
Accept with no changes | 2 |
Accept with the following changes | 3 |
Do not accept for the following reasons |
(1 response didn't contain an answer to this question)
Responder | Review proposal for Action 13: Write up on selectors 4.1 | Comments |
---|---|---|
Wilco Fiers | Accept with the following changes | I think the language is a little too technical. We can probably simplify. As for CSS Selectors, often those turn out to be insufficient to do all the work we want to be able to do. CSS Selectors are tied to DOM elements, where as the type of selector we'd talk about may include looking at the way an element is styled. |
Shadi Abou-Zahra | Accept with no changes | Minor: Are selectors always boolean? I thought some return integers (like line numbers), but I'm not sure what the formal definition is. Can't we just simplify the sentence to something like "A selector tests for the occurrence of elements and components in the input data according to a match expression." |
Romain Deltour | Accept with the following changes | s/plain English/plain language/ For my other comments, see the PR :-) |
Mary Jo Mueller | I think I need to defer to the rest of the group, as I'm need a little education on what selectors are supposed to represent to understand if this is a good definition or not. | |
Charu Pandhi | Accept with no changes | |
Maureen Kraft | Accept with the following changes | Selectors may select one or more elements or components. |
Review the following updated text proposed for the Rule Description section 2.2 of the Accessibility Conformance Testing Framework Requirements document in response to the 7 December survey results for question 3 and the discussion from the 7 December meeting.
Each ACT Rule MUST have a description that:
Choose one of the following and record your comments, in the github conversation tab for pull request #12 (preferred) or in the comment box below.
Choice | All responders |
---|---|
Results | |
Accept with no changes | 5 |
Accept with the following changes | 1 |
Do not accept for the following reasons |
Responder | Re-review proposal for Action 11: Draft of section 2.2 rule description | Comments |
---|---|---|
Wilco Fiers | Accept with no changes | I think this is a good start, be we should probably elaborate on these items a bit. |
Shadi Abou-Zahra | Accept with no changes | |
Romain Deltour | Accept with no changes | |
Mary Jo Mueller | Accept with no changes | |
Charu Pandhi | Accept with no changes | |
Maureen Kraft | Accept with the following changes | Should we state plain English? |
Review the following update proposed for the Introduction section of the Accessibility Conformance Testing Framework Requirements document in response feedback received during the 7 December ACT TF meeting: 7 December Meeting Minutes.
The Accessibility Conformance Testing Framework (ACT Framework) defines a set of requirements, format and measurable qualities to produce a transparent set of accessibility test methods that produce consistent validation results. This work will lead to a more common understanding by accessibility experts on how to test accessibility standards, such as WCAG 2.0. In support of this framework is a set of test descriptions, known as Accessibility Conformance Testing Rules (ACT Rules) which define test descriptions that meet the requirements outlined by the ACT Framework.
Choose one of the following and record your comments in the conversation tab of pull request #20 (preferred) or in the comment box below.
Choice | All responders |
---|---|
Results | |
Accept with no changes | 5 |
Accept with the following changes | |
Do not accept for the following reasons |
(1 response didn't contain an answer to this question)
Responder | Re-review proposed update to the Introduction section | Comments |
---|---|---|
Wilco Fiers | Accept with no changes | |
Shadi Abou-Zahra | Accept with no changes | |
Romain Deltour | Maybe it's just me (non-native –and tired– English speaker) but some parts lack clarity imho (and sorry if I haven't spotted that in last week's survey): - the first sentence is long and maybe difficult to parse? - not sure I understand the "transparent" in "transparent set of accessibility test methods" - "In support of this framework...": not sure that "support" is the right idea here; ACT Rules don't support the framework like Understanding and Techniques support WCAG. ACT Rules are more an implementation of the framework, no? Also, since the WG isn't chartered for writing Rules, can we make that assumption? | |
Mary Jo Mueller | Accept with no changes | |
Charu Pandhi | Accept with no changes | |
Maureen Kraft | Accept with no changes |
Review the following update proposed for the Scope section of the Accessibility Conformance Testing Framework Requirements document in response to Issue 5: ACT Framework Requirements document is too general.
This document is an early draft. It has been updated based on initial feedback from the WCAG Working Group.
The work has been incubated in the Auto-WCAG Community Group for over 2 years, which has shown a growing interest in harmonized accessibility testing. Development and implementation of ACT Rules are outside the scope of the ACT Framework. This work is currently done within the [Auto-WCAG Community Group](https://www.w3.org/community/auto-wcag/). The ACT Taskforce will support the Auto-WCAG Community group in the development of the first set of ACT Rules.
Rules will be developed as part of the project as evidence that the ACT Framework is capable of targeting different accessibility requirements for web content and digital publications.
The ACT Framework is created to develop rules for the conformance of web technologies, including those used in digital publishing. This includes technologies such as HTML, CSS, WAI-ARIA, SVG and more. The ACT Framework is designed to be technology agnostic, meaning it has no specific technology in mind. This also means that the ACT Framework could conceivably be used for other technologies. Whether or not this is the case depends on the specific technology.
Accessibility requirements such as Web Content Accessibility Guidelines, which is specifically designed for web content, can be tested using ACT Rules. Other accessibility requirements that would also be applicable to web technologies should also be testable with ACT Rules. Because some of those accessibility requirements may be applicable to technologies other than web technologies, the ACT Framework may not be suitable for every part of this requirement.
For example, the User Agent Accessibility Guidelines 2.0 is applicable to web-based user agents, for which ACT Rules could be developed, but other technologies can also be used to develop User Agents, which are not web-based.
Choose one of the following and record your comments in Issue 5 (preferred) or in the comment box below.
Choice | All responders |
---|---|
Results | |
Accept with no changes | 2 |
Accept with the following changes | 3 |
Do not accept for the following reasons |
(1 response didn't contain an answer to this question)
Responder | Review proposed update to the Scope section | Comments |
---|---|---|
Wilco Fiers | Accept with no changes | |
Shadi Abou-Zahra | Accept with no changes | |
Romain Deltour | Accept with the following changes | a) I don't think we should be entirely technology agnostic. I think HTML for instance can be assumed? In any case, the statement might sound a bit contradictory with the previous sentences ("designed for techno X but not designed with any specific techno in mind"). Aren't we risking to be too encompassing here? b) I find the second paragraph a bit difficult to parse. We should at least fix some inconsistencies: "web content" vs "web technologies", "those requirements" vs "tjis requirement". |
Mary Jo Mueller | Accept with the following changes | In the scope, I don't quite understand the statement, "Because some of those accessibility requirements may be applicable to technologies other than web technologies, the ACT Framework may not be suitable for every part of this requirement." I'm not sure what to suggest to make it better. Is it trying to convey something like this: "Since WCAG requirements are sometimes applied to non-Web technologies, the ACT Framework may not be suitable to fully determine compliance to that requirement." If not, I'm not sure what it's trying to convey. Which accessibility requirements is the ACT Framework not suitable for testing every part of "this requirement"? The last sentence doesn't really clear this confusion up for me. |
Charu Pandhi | Accept with the following changes | Having some difficulty understanding these 2 sentences, further clarification may be needed: Other accessibility requirements that would also be applicable to web technologies should also be testable with ACT Rules. Because some of those accessibility requirements may be applicable to technologies other than web technologies, the ACT Framework may not be suitable for every part of this requirement. |
Maureen Kraft |
The following persons have not answered the questionnaire:
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
w3c/wbs-design
or
by mail to sysreq
.