- From: Doug Schepers <schepers@w3.org>
- Date: Fri, 11 Dec 2015 10:57:22 -0500
- To: SVG WG axs TF TLA ?-f ... <public-svg-a11y@w3.org>
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SV_MEETING_TITLE
11 Dec 2015
See also: [2]IRC log
[2] http://www.w3.org/2015/12/11-svg-a11y-irc
Attendees
Present
Fred, AmeliaBR, chaals, Rich_Schwerdtfeger, shepazu,
LJWatson, Jason, fesch, Doug
Regrets
chaals
Chair
Fred
Scribe
Jason
Contents
* [3]Topics
1. [4]testing
* [5]Summary of Action Items
* [6]Summary of Resolutions
__________________________________________________________
<fesch>
[7]https://mit.webex.com/mw3000/mywebex/default.do?service=1&si
teurl=mit&nomenu=true&main_url=%2Fmc3000%2Fe.do%3Fsiteurl%3Dmit
%26AT%3DMI%26EventID%3D356001467%26UID%3D0%26Host%3DQUhTSwAAAAL
pR-7HvddPbTO7lzrKke3ZQkMhzViW3Zbvsj1Z9qdThoaUVLfO-j77RsT8rTwbLk
1Z2jJOe81OVWTDEJnxO-q70%26FrameSet%3D2%26MTID%3Dm7fe38709ab1505
408e44af52147625ca
[7]
https://mit.webex.com/mw3000/mywebex/default.do?service=1&siteurl=mit&nomenu=true&main_url=%2Fmc3000%2Fe.do%3Fsiteurl%3Dmit%26AT%3DMI%26EventID%3D356001467%26UID%3D0%26Host%3DQUhTSwAAAALpR-7HvddPbTO7lzrKke3ZQkMhzViW3Zbvsj1Z9qdThoaUVLfO-j77RsT8rTwbLk1Z2jJOe81OVWTDEJnxO-q70%26FrameSet%3D2%26MTID%3Dm7fe38709ab1505408e44af52147625ca
<fesch> agenda
[8]https://mit.webex.com/mw3000/mywebex/default.do?siteurl=mit&
service=1&main_url=%2Fmc3000%2Fmeetingcenter%2Fdefault.do%3Fsit
eurl%3Dmit%26main_url%3D%252Fmc3000%252Fmeetingcenter%252Fmeeti
ngend%252Flandingpage.do%253Fsiteurl%253Dmit%2526ishost%253Dfal
se%2526NM%253DFred%252BEsch%2526AD%253Dfesch%2540us.ibm.com%252
6STD%253D1&rnd=-1917584270
[8]
https://mit.webex.com/mw3000/mywebex/default.do?siteurl=mit&service=1&main_url=%2Fmc3000%2Fmeetingcenter%2Fdefault.do%3Fsiteurl%3Dmit%26main_url%3D%252Fmc3000%252Fmeetingcenter%252Fmeetingend%252Flandingpage.do%253Fsiteurl%253Dmit%2526ishost%253Dfalse%2526NM%253DFred%252BEsch%2526AD%253Dfesch%2540us.ibm.com%2526STD%253D1&rnd=-1917584270
<fesch> scibe: Jason
<fesch> scribe: Jason
testing
<fesch> [9]http://www.w3.org/2015/12/10-aria-minutes.html
[9] 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>
[10]https://github.com/w3c/aria/tree/master/testfiles/1.0
[10] 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_i
d=1&testcase_id=749
<fesch>
[11]https://www.w3.org/WAI/PF/testharness/testreport?testsuite_
id=1
[11] 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> [12]https://www.w3.org/wiki/SVG_Accessibility/Testing
[12] 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.
Summary of Action Items
Summary of Resolutions
[End of minutes]
Received on Friday, 11 December 2015 15:57:41 UTC