Evaluation and Repair Tools Working Group Teleconference

Review of WCAG-EM

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2013Dec/0005.html

SAZ: Announcement: review of WCAG-EM
... Developed by Evaluation Task Force.
... Survey open until 17 December.
... Now looking primarily for things that need to be addressed before WCAG-EM will be published as a draft.
... Can also submit comments that you think can be addressed after publication as a draft, but please make it easy to distinguish comments that need to be addressed before or after publication.
... Some sections (esp. section 4) have many changes since the previous draft. Section 4 might need more work.
... WCAG WG will also be reviewing the doc, esp. section 4.
... Link to the draft is available in the survey. Disposition of previous comments is also available.
... when would you be able to review this document?
... Implicit deadline of Friday 13 December? So we can get resolutions during the week after that?
... Focus mainly on big issues with the draft.

Review of AERT (working title) Editor Draft

See http://www.w3.org/WAI/ER/WD-AERT/ED-AERT

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2013Dec/0002.html

SAZ: Carlos worked on improvements in several sections.

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2013Nov/0003.html

SAZ: Question about the title of the document.

<shadi> "and assessment"

SAZ: Currently can't think of a better title. Samuel's suggestion is to drop the "and assessment" aspect from the title.

<shadi> "Guidance on the development and assessment of

<shadi> web accessibility evaluation tools"

SAZ: Assessment seems a secondary goal at the moment.
... Would add complexity to the document.
... So primary focus would be how developers can create better tools for evaluating WCAG 2.

Carlos: We can drop it from the title but we should still keep it somewhere in the document ...
... The assessment is also important, so you can use the document in both directions.

SAZ: Achieving more goals is better, but how easy is it to combine both goals?

Carlos: Don't think we extend the scope to much. Don't see this as a major risk.

CS: Think that the same criteria or features would need to be formulated in different ways for the two audiences: developers and the one hand and evaluation tool users on the other.

SAZ: More narrative descriptions - there were comments on this. Because writing for an audience of users of such tools is different from writing for developers. E.g. explaining what crawling is.
... Not saying that these can't be combined, but it would extend the scope of the audience.

Carlos: Would like it to be formulated as precise and neutral as possible.

<shadi> http://www.w3.org/WAI/ER/conformance/ED-methodology-reqs-20111012

SAZ: Don't need to decide this today. Need to look at the requirements.
... see "target audience": http://www.w3.org/WAI/ER/conformance/ED-methodology-reqs-20111012#audience

Samuel: Secondary audience also covers users of ERT tools.

<shadi> http://www.w3.org/WAI/ER/WD-AERT/ED-requirements

<shadi> [[The document "Techniques for Automated and Semi-Automated Evaluation Tools" is targeted mainly to development managers and developers of web accessibility evaluation tools. Under this scope, we will not distinguish between commercial and open source developers, although there are use cases that could be more relevant to one group than to the other.

<shadi> A secondary audience of this document are users of accessibility evaluation tools like accessibility experts or web developers.]]

SAZ: Objectives don't talk so much about comparison or assessment of tools.
... Risk of scope creep. So we need to decide whether we want to extend the scope. Advantage is bigger audience. Downside is more discussion about how to formulate the features.
... If we address the assessment aspect, some users might find the descriptions too concise.
... It seems we have a narrower scope than what the title suggests.
... So I propose to remove "assessment" from the title. We also need a shorter title.
... As homework for all: think about whether we need to reopen the scope as discussed in the requirements document.
... Carlos to think about whether extending the audience looks like a manageable effort, given the deadline of 8 months.

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2013Dec/0004.html

<shadi> [[I've noticed some modal verbs have been changed, but I cannot see a

<shadi> pattern. I know modal verbs are used in this document with its plain-English

<shadi> meaning, instead of the sense defined by RFC 2119 (the capitalized,

<shadi> standard-meaning versions such as MUST, SHOULD, MAY, etc.) Nonetheless, I

<shadi> understand there is a rationale behind using "can", "could", "may", or

<shadi> "should", however I am not sure if it is consistently followed throughout

<shadi> the document.]]

Carlos: Samuel seems to referring mainly to "must" etc.

Samuel: Can try to find examples of changes.

Carlos: "musts" that have disappeared.

<shadi> "This document must be seen in the context of several others. Complementary information can be found in the following documents and those cited in the references section:"

SAZ: Background reading document: "must".

<shadi> "This document is part of complementary resources:"

SAZ: part of a set of complementary resources.

<shadi> "In general, we can distinguish these types of content formats"

<shadi> "Some types of content formats include"

SAZ: In section 2.1.1 (http://www.w3.org/WAI/ER/WD-AERT/ED-AERT#typedoc) both "we" and "can" are issues.
... Also important to be non-exclusive, since we know the list is not complete.

Samuel: Found some more examples of "should" etc.

<samuelm> 2.1.3 the tool could filter the accessibility tests according to their relevance to the document fragment.

<samuelm> the tool could be able to generate a document fragment

Samuel: Sometimes "could", elsewhere "may".

<shadi> "Tools that evaluate such applications should emulate and record different user actions ..."

<samuelm> accessibility testing tool should be able to support

Samuel: My concern is: when do we say "could" and when "should"? "May" instead of "could"?

<shadi> "Furthermore, the tool could filter the accessibility tests according to their relevance to the document fragment"

SAZ: See also 2.1.3 and 2.1.4.

<shadi> "Tools that evaluate such applications should emulate and record different user actions ..."

SAZ: Consistence between the sentences is also important.

<carlos> could be :-)

SAZ: also "furthermore"
... This introduces another feature.

Carlos: Reformulate it?
... To avoid strong modals like "must" - soften them. E.g. section about fragments.

"May" can mean that some tools have the feature and some don't. "Could" does not sound like something that native speakers would use here. Should ask a native speaker?

"Could" sounds too much like speculation about whether tools are able to implement the feature.

SAZ: generate a document fragment?

Carlos: This is DOM jargon.

SAZ: OK, but the sentence should be formulated more clearly.

Carlos: There are documents and document fragments. The sentence talks about evaluation tools here.
... The tool generates document fragments.

SAZ: The first sentence talks about fragments coming from the editor. This contradicts the explanation that the fragments come from the evaluation tool.

Carlos: The text comes from the editor; the tool generates the document fragment.

SAZ: Try to bypass the coulds, mays and shoulds. Also get rid of the mismatch between the two sentences in 2.1.3.
... Perhaps make the feature stand out more. When you need to use modal verbs, make sure to use them consistently.

Carlos: It depends on the sentence whether "should" is needed or "could".

SAZ: They have different meanings. Depends on what you want to convey.
... Next meeting next week.