RE: HTML Executables for Testing Statements Now Complete

Hi Joanie,
I added aria-owns mappings and bidirectional parsing, and fixed all of the issues you reported, with a couple of exceptions. These are now live at the same urls as before, testable from:
https://whatsock.github.io/w3c-alternative-text-computation/Autogenerated%20AccName%201.1%20Testable%20Statements%20-%20W3C/index.html 

There are a few however that I'm unclear about.

(Name test case 548)
I corrected the one you mentioned here
https://whatsock.github.io/w3c-alternative-text-computation/Autogenerated%20AccName%201.1%20Testable%20Statements%20-%20W3C/Name%20test%20case%20548.html 
Which computes the name for the following markup, but it does so by parsing the underlying select markup and has nothing to do with the ARIA Menu roles, which seem like a seriously bad use of ARIA. The reason being that menuitems don't support a selected state, so the results of this test are misleading.

<select name="member" tabindex="0" role="menu" size="1">
      <option role="menuitem" selected="true" value="beard">clown</option>
      <option role="menuitem" value="scuba">rich</option>
    </select>

(Name test case 661)
Also, regarding this testable statement:
https://whatsock.github.io/w3c-alternative-text-computation/Autogenerated%20AccName%201.1%20Testable%20Statements%20-%20W3C/Name%20test%20case%20661.html 
In your bug report you mentioned that the expected Name property should be the value of the title attribute, but I think this is incorrect according to the spec naming computation, since the title attribute is only supposed to be used as the accessible name when there is no set value for aria-labelledby or aria-label or a valid labelling mechanism such as text from content, and in this case, text from content is being set by the CSS pseudo elements that append their textual values within the explicit label for the form field. So if text from content is available, the textual label becomes the Name and the Title becomes the Description. If I am misunderstanding this, please let me know.

(Name checkbox-label-embedded-menu) Regarding this one
https://whatsock.github.io/w3c-alternative-text-computation/Autogenerated%20AccName%201.1%20Testable%20Statements%20-%20W3C/Name%20checkbox-label-embedded-menu.html 
I think all of these testable statements that reference the use of embedded menus are flawed, because menuitem doesn't support a selected state:
http://www.w3.org/TR/wai-aria-1.1/#menuitem 
As such, they cannot be parsed in the same manner as a selectable listbox widget.

I've also created a series of proposed test statements in a folder named "Proposed Name and Description Tests", which you can see and test by downloading or cloning the repo at
https://github.com/whatsock/w3c-alternative-text-computation 

These include more advanced tests that deal with the finer details, such as aria-owns parsing and how this translates to the accessible name, the differences between block and inline element types, and some that are actually unclear according to the spec.

The ones that are unclear are named
"Description description-title-same-element.html", which deals with setting both a title and aria-describedby and exposes what is currently happening in browsers as opposed to what probably should be happening.
"Name checkbox-label-multiple-label.html" and "Name checkbox-label-multiple-label-alternative.html", which exposes two opposing ways that multiple explicit labels might be implemented, and there is nothing in the spec that says how to compute the name for both together.
"Name file-label-inline-hidden-elements.html", which addresses John's desire for one with hidden elements, which includes many different forms of hiding content to test them all at once, and even includes aria-hidden="false" on a hidden element just to throw a wrench into the works because we have to make a final decision whether browsers should or should not include this in the naming computation.

There is now a version string at the bottom that is automatically generated to reflect the current recursion.js code being run, so if bugs are detected passing along the version might be important in some cases.

All the best,
Bryan


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

-----Original Message-----
From: Joanmarie Diggs [mailto:jdiggs@igalia.com] 
Sent: Thursday, February 22, 2018 6:21 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Cc: 'ARIA Working Group' <public-aria@w3.org>
Subject: Re: HTML Executables for Testing Statements Now Complete

Bryan, have I mentioned you rock? <smiles> Thank you so much for doing this work!

I've compared what your tool says the name should be with what the ARIA
1.0 expectations were/are. There are some discrepancies. In some cases I think our expectations are right. In some cases, I'd have to look at the algorithm. Since I need to investigate mappings on macOS and likely update the platform expectations accordingly, it would be great if you could investigate the discrepancies. I've detailed them here:
https://github.com/WhatSock/w3c-alternative-text-computation/issues/6


Thanks again *very* much!!
--joanie

On 02/20/2018 02:32 AM, Bryan Garaventa wrote:
> Hi,
> As requested I added all of the testable statements as executable HTML 
> files in the archive at 
> https://github.com/whatsock/w3c-alternative-text-computation

> 
> I started doing this individually, and found that it was brain numbingly boring and tedious, so I wrote a JScript application that will do this automatically, which I've added to the repo in case it's useful for anybody else. I think this only works on Windows; I'm not sure if WScript is executable elsewhere.
> 
> This also automatically generates an index.html file in the same folder for easy testing on webservers:
> https://whatsock.github.io/w3c-alternative-text-computation/Autogenera

> ted%20AccName%201.1%20Testable%20Statements%20-%20W3C/index.html
> 
> When the Testable Statements wiki page is updated, running this script will refresh the list and add the new tests automatically.
> 
> As requested, I'll continue going through them to identify those that are missing, but this takes care of the lionshare of what I was tasked to do at present.
> 
> All the best,
> Bryan
> 
> 
> 
> Bryan Garaventa
> Accessibility Fellow
> Level Access, Inc.
> Bryan.Garaventa@LevelAccess.com
> 415.624.2709 (o)
> www.LevelAccess.com
> 
>

Received on Saturday, 24 February 2018 02:01:08 UTC