add error handling for missing attrs in aria-utils.js

[cookiecrook]

A colleague mentioned they'd put data-expectedname in the markup instead of data-expectedlabel, but verifyLabelsbySelectors() didn't give a clear error that the attr was actually missing. Presumably it just called el.getAttribute('data-expectedlabel') and got back an empty string for the comparison.

We can probably fix that and similar issues by throwing more errors or warnings in several places.

[rahimabdi]

Agreed! I was also curious why we weren't using "name" across the board (as opposed to data-expectedlabel, verifyLabelsBySelector()) but I see you touched on the rationale here: #65 (comment).

[cookiecrook]

For completeness, "name" is common in Windows Accessibility APIs, but not Mac/iOS. There are concepts of accessible labels on all platforms, but IIRC only Window makes the distinction between the terms assuming label has to be rendered text or something similar that is used for the name. Early on, MacOS used AXTitle/AXDescription similarly to how Windows used label/name. I got involved in ARIA in 2006 or so, in part to fix many overlooked things related to Apple platforms; including the Windows-centric keyboard shortcuts, and several misunderstandings of how aria-describedby should be mapped (It's not the same concept as AXDescription)…

Since there were already a number of unrelated-to-accessibility uses of "name" in the Web Platform, the ARIA WG went with aria-label/aria-labelledby (British spelling of "labelled" for some reason).

"computed label" follows that pattern... I recall the reason AccName uses "name" is mainly editorial—as in, the primary editor at the time came from the Windows side and liked "name" better. There were a number of Windows-style artifacts in the original ARIA spec. Many still exist in some form.

[cookiecrook]

@janewman interested in this issue. Will work with @benbeaudry or @chrishtr to get into the Interop GH team.