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

Re: Sanity checking one of the name calculation test cases

From: James Nurthen <nurthen@adobe.com>
Date: Wed, 9 May 2018 19:57:59 +0000
To: "Gunderson, Jon R" <jongund@illinois.edu>, Joanmarie Diggs <jdiggs@igalia.com>, ARIA Working Group <public-aria@w3.org>
Message-ID: <MWHPR02MB26536BCEC8CDC2A1D3CC5445A6990@MWHPR02MB2653.namprd02.prod.outlook.com>
+1

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Gunderson, Jon R <jongund@illinois.edu>
Sent: Wednesday, May 9, 2018 12:43:51 PM
To: Joanmarie Diggs; ARIA Working Group
Subject: RE: Sanity checking one of the name calculation test cases

Joanie,

I agree remove this test.

Jon


-----Original Message-----
From: Joanmarie Diggs [mailto:jdiggs@igalia.com]
Sent: Wednesday, May 9, 2018 2: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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2Fwiki%2FAccName_1.1_Testable_Statements%23Name_test_case_663&data=02%7C01%7Cnurthen%40adobe.com%7Cf5c333017f7544da6c2808d5b5e57079%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636614919410865165&sdata=RyqdYoaUd1QS35OYLjxWm%2Fxn8sNRkxlVPCtr5Muf6mQ%3D&reserved=0
[2]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fhtml-aam%2F%23input-type-button-input-type-submit-and-input-type-reset&data=02%7C01%7Cnurthen%40adobe.com%7Cf5c333017f7544da6c2808d5b5e57079%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636614919410865165&sdata=QW7siy4KHwfDI26R7U4ndOjECc48n94hKczsHD%2BITAI%3D&reserved=0
[3] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fhtml-aam%2Fissues%2F134&data=02%7C01%7Cnurthen%40adobe.com%7Cf5c333017f7544da6c2808d5b5e57079%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636614919410865165&sdata=XycpQWwoORIJISMFJ9rdLyUmMKT1U8alAIprbBANl2s%3D&reserved=0
[4]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2Fwiki%2FAccName_1.1_Testable_Statements%23Name_test_case_663a&data=02%7C01%7Cnurthen%40adobe.com%7Cf5c333017f7544da6c2808d5b5e57079%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636614919410865165&sdata=katxfUjTPB8%2B7OJoDj8kpEQrB3WyYPFM6axHMHf9Aas%3D&reserved=0
Received on Wednesday, 9 May 2018 19:58:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 9 May 2018 19:58:30 UTC