See also: IRC log
<fesch> scibe: Jason
<fesch> scribe: Jason
<fesch> http://www.w3.org/2015/12/10-aria-minutes.html
Fred notes the minutes from yesteday's ARIA meeting.
Fred: we need to test the roles,
states and properties. However, we didn't introduce any states
and properties. Thus we need to test the roles and the name and
description computation.
... we could choose to have either SVG files or HTML 5 files
with embedded SVG.
Fred asks for preferences and whether it's possible to test with stand-alone SVG files.
Doug: for every test we should do
both: sometimes users will encounter a stand-alone SVG and in
other cases SVG embedded in HTML.
... we create one test in stand-alone SVG, then create a
harness that inlines it in HTML.
Doug clarifies: it embeds it in an HTML wrapper.
Leonie: screen reader support differs radically depending on whether the SVG is embedded in HTML. For example, MMSIE/windows screen readers only recognize SVG included in HTML documents.
Leonie clarifies that we need to test both.
Responding to Fred: Leonie suggests a test that distinguishes browser/screen reader combinations that do or do not recognize stand-alone SVG, then offer a suitable combination of tests according to the result of this first test.
Doug: there may be cases in which
there is a difference between stand-alone SVG and SVG in HTML,
but we don't know. It's trivial to make the tests stand-alone,
then run a script to embed the test cases in HTML.
... if the tests (as hoped) are automated, then running the
tests is trivial.
... it's trivial to double the number of test cases with such a
script.
He also notes that bugs and their causes can be unpredictable, hence we should test thoroughly.
Fred: for ARIA testing, it isn't clear what can be automated.
Amelia would like to see the data aggregated automatically even if a human evaluator has to decide whether the test passes or fails.
Doug inquires why it an't be automated. The problem is that browser developers doing regression testing are not therefore assessing accessibility issues.
Amelia: if we wanted to automate
the tests, we would need separate tests for each
browser/operating system combination, since the ARIA specs
recommend what should appear in each platform's accessibility
API. This can't be automated with a JavaScript test; it has to
be done at a higher level for each accessibility API.
... we could offer to help browser development teams to build
automated testing systems and confirm that their tests match
ours.
Fred: verification is in the accessibility tree, which is not easy to expose.
Doug disagrees, arguing that for performing accessible name computation, one doesn't need to work at the accessibility API level; in-browser testing could be done using WebDriver.
Doug: the code that serves as the interface between the browser and the platform should be capable of being exposed to WebDriver.
Leonie notes ongoing discussions with WebDriver developers.
Doug notes the importance of addressing this problem so that the tests can be automated.
<fesch> jw: were proposals in for cross platform API which would help testing, currently there is an internal APIs...
Fred notes that Joanie Diggs is interested in finding ways of automating the tests. What is in the accessibility tree (as revealed to the AT) is the conformance criterion.
Fred suggests that we start with SVG in HTML, then providing a harness to produce stand-alone SVG files.
Amelia: the starting point has to be to create a definition of the marked up examples and what the behavior for each should be.
<fesch> <!DOCTYPE html>
Amelia: the question is which form (embedded or stand-alone) to start with.
<fesch> <html>
<fesch> <head>
<fesch> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<fesch> <title> </title>
<fesch> </head>
<fesch> <body>
<fesch> </body>
<fesch> </html>
Responding to Amelia's question, Fred indicates that there already exists a template for the SVG included in HTML.
<fesch> https://github.com/w3c/aria/tree/master/testfiles/1.0
Amelia: there needs to be a test description of what the user has to do to determine whether the test passes.
<fesch> ttps://www.w3.org/WAI/PF/testharness/testcases/edit?testsuite_id=1&testcase_id=749
<fesch> https://www.w3.org/WAI/PF/testharness/testreport?testsuite_id=1
Fred: multiple tests may be run on a single file. Thus we distinguish the SVG file from the test cases that may embed the SVG content in HTML.
He also notes that we'll use HTML 5 rather than HTML 4.
Doug recommends authoring the tests in stand-alone SVG, then using a tool to create the HTML-embedded versions by using an HTML wrapper in a uniform manner.
Amelia: we also need to write the instructions and relate them to the actual markup.
<fesch> https://www.w3.org/wiki/SVG_Accessibility/Testing
<fesch> jw: starting from the SVG makes sense
Doug's first impression of the testable statements is favorable.
He maintains it should be easy to create a generator that produces the test files.
Doug offers to do it if nobody else will.
Fred offers to work on it in Perl.
It is agreed that Perl should handle this easily with regular expression matching.
Fred envisages it as a two-pass process: (1) to create the HTML, and (2) to introduce the SVG.
Responding to Fred, Amelia offers to verify the testable statements.
Fred suggests the effort should be shared.
Fred: at the ARIA meeting, it was suggested to concentrate on the positive statements and be less exhaustive about, e.g., what shouldn't make it into the accessibility tree.
Amelia: we could have a test taht provides many elements which shouldn't appear in the accessibility tree, then evaluate the results.
Responding to Fred's comment that the element to be tested needs to have id="test" (by convention), Amelia maintains that in more complex cases, this element will need to contain an element hierarchy.
Doug: if text content appears in a non-rendering element it wouldn't be rendered in SVG but should appear in a browser that doesn't support SVG. He wonders whether we should test this kind of case.
Amelia: plain text content would be ignored for purposes of the name and description computation where it doesn't have significance according to the SVG spec. Such text does, however, serve as good fallback content for browsers that don't support SVG, and we may need to consider how it should appear in the accessibility API mappings.
Doug notes that we need a rule to determine this.
Amelia: fallback content is for all browsers, not for screen readers as such, and we should have a test to ensure that it's ignored appropriately.
Responding to Doug, Amelia clarifies taht ignoring the text content in such cases is only to be done in browsers that otherwise pass the ARIA tests and impelemnt SVG, revealing the content to the AT as a structured graphic with titles and descriptions.
Doug argues that the text content should be revealed if taht's all there is.
Amelia worries that this would complicate the rules and the testing.
Amelia: perhaps it should be
revealed where no other content is provided that would appear
in the accessibility tree.
... there need to be tests related to revealing text content,
e.g., in text elements.
Fred suggests adding a section on this point to the wiki.
He also thinks we should be consistent with what ARIA does more generally.
Fred: for the rest of the year we should focus on testing; other agenda items should be sent to Fred for next week's meeting. Thereafter, we resume in January.
Fred proposes to issue a poll on meeting times. There will also be a working issue tracker.
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: jasonjgw Found Scribe: Jason Default Present: Fred, AmeliaBR, chaals, Rich_Schwerdtfeger, shepazu, LJWatson, Jason, fesch, Doug Present: Fred AmeliaBR chaals Rich_Schwerdtfeger shepazu LJWatson Jason fesch Doug Regrets: chaals WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Got date from IRC log name: 11 Dec 2015 Guessing minutes URL: http://www.w3.org/2015/12/11-svg-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]