W3C home > Mailing lists > Public > public-aria@w3.org > May 2018

RE: Sanity checking one of the name calculation test cases

From: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Date: Thu, 10 May 2018 16:55:50 +0000
To: Joanmarie Diggs <jdiggs@igalia.com>, ARIA Working Group <public-aria@w3.org>
Message-ID: <BN7PR03MB365070251921601280ECBFD0F2980@BN7PR03MB3650.namprd03.prod.outlook.com>
Sounds good to me.

If a new executable test file needs to be created on my end to cover any tests please let me know and point me to the correct ones in the wiki, then I'll add these to the archive for uploading.


Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: Joanmarie Diggs <jdiggs@igalia.com> 
Sent: Wednesday, May 09, 2018 12:34 PM
To: ARIA Working Group <public-aria@w3.org>
Subject: Sanity checking one of the name calculation test cases

Hey all.

Name test case 663 [1] has expectations that seem a) beyond our spec and
b) potentially wrong. The test case is:

======
if given
  <style type="text/css">
    label:before { content: "foo"; }
    label:after { content: "baz"; }
  </style>
  <form>
    <label for="test">
      <input id="test" type="file" name="test" title="bar">
    </label>
  </form>
then the accessible name of the element with id of "test" is "foo bar baz"
======

User agents are including the "foo" and "baz". But they are not including "bar". Instead, they are including the text displayed on the button, such as "Browse...".

My thoughts:

The behavior I'm seeing is consistent with what the HTML-AAM states for other buttons (like submit and reset). [2] Mind you, the HTML-AAM doesn't explicitly address the file input button scenario, so I've filed an issue against that spec so that they can fix that. [3]

Back when I initially saw this behavior/failure with test case 663, I created a test that was the same but used an input type of "image"
instead of file. That is test case "663a" [4]. It passes. So we have coverage for the general scenario.

I believe testing what happens with the file input should be done as part of HTML-AAM testing; not Accname testing. That, plus the fact that we have coverage for the general scenario in 663a, has led me to conclude that the correct thing to do is remove this test from our CR-exit-criteria suite. Any objections?

--joanie

[1]
https://www.w3.org/wiki/AccName_1.1_Testable_Statements#Name_test_case_663

[2]
https://w3c.github.io/html-aam/#input-type-button-input-type-submit-and-input-type-reset

[3] https://github.com/w3c/html-aam/issues/134

[4]
https://www.w3.org/wiki/AccName_1.1_Testable_Statements#Name_test_case_663a


Received on Thursday, 10 May 2018 16:56:25 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 10 May 2018 16:56:26 UTC