See also: IRC log
http://www.w3.org/WAI/ER/methodology/
saz: putting together the final editor draft
... expect to have it ready by Monday 23 June for WG review
... this includes ERT WG review
... want to publish this as final WG Note
... would like comments by 1st July
... did some re-organization and many editorial improvements
... but to our understanding not many substantial changes
... think we closed all comments raised over the previous rounds
cv: will try to get someone to review
sm: if not many substantial changes as said, then could do the quick review
saz: will let you know the outcomes of the review on 2nd July call
https://github.com/w3c/wcag-em-report-tool/
saz: tool to support users of WCAG-EM
... helps generate reports based on WCAG-EM
cv: seems useful
saz: uses EARL to record the data
... also extends it with WCAG-EM specific concepts like "structured sample"
... uses JSON serialization to export and import
cv: issue that we do not know of a good
JavaScript library for RDF
... curious how the developers handle this
saz: EC-project called EIII interested in extending this tool by allowing evaluation tools to populate the reports
http://www.w3.org/WAI/accessibility-support/
https://github.com/w3c/wai-axsdb-web/issues
http://lists.w3.org/Archives/Public/public-wai-ert/2014Jun/0001.html
saz: think main point is (1) positioning and explaining what the document does, and (2) using clearer language to make it easier to understand
cv: are these show-stoppers? can we address during review?
saz: concerned that if the purpose and contents of the document is not clearly explained upfront, then people may not realize that it is relevant to them and we may not get any comments
sm: need to target tool developers as these are
our primary target audience
... comments make sense, especially on clarifying the target
... not sure the proposed suggestions are the correct ones though
... need to reach out to tool developers and make sure the document gets to
them
[[the purpose is to *encourage the development* of more of the features that you describe, rather than just naming and describing potential features]]
saz: do we agree with this?
cv: not sure why this is an issue
... not mutually exclusive
sm: to help developers make informed decisions,
rather than to encourage the development of features
... want developers to understand why they are implementing certain
features
"content that can tested"
"supported content"
<samuelm> "resources under testing"?
"traversing content"
"fetching content"
<scribe> ACTION: carlos to brainstrom alternatives for "test subject and its environment" [recorded in http://www.w3.org/2014/06/18-er-minutes.html#action01]
<trackbot> Error finding 'carlos'. You can review and register nicknames at <http://www.w3.org/WAI/ER/tracker/users>.
2nd July