See also: IRC log
<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.
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.