[whatwg] Linters should complain about missing accessible names for controls [Was: Re: alt="" and the <meta name=generator> exception]

[Benjamin Hawkes-Lewis]

On Sun, Aug 5, 2012 at 2:14 PM, Henri Sivonen <hsivonen at iki.fi> wrote:
> On Sat, Aug 4, 2012 at 10:32 PM, Benjamin Hawkes-Lewis
> <bhawkeslewis at googlemail.com> wrote:
>> Would it be possible to combine this with the linter complaining about
>> all controls (links, buttons, form fields) have markup that yield a
>> non-empty "accessible name" without invoking repair techniques such as
>> reading filenames without img @src attributes?
>
> Given a well-defined algorithm for finding the accessible name for
> links, buttons and form fields, I think it would make sense for a
> validator to be able to complain when the algorithm results in an
> empty accessible name.

OK … that sounds promising.

> Whether that should be a validity constraint or
> an optional additional check is a bit tricky, for the same reason why
> we allow empty paragraphs and empty lists: to let markup editors
> simultaneously guarantee the validity of their output and to allow the
> user to save the document at any stage of editing.
>
> (Again, there's tension between different uses of validity: the sort
> of validity constraints you want to hold before and after each
> discrete editing operation and constraints you want to hold when the
> document is "done".)

I really don't think you can resolve that tension except by profiling
the requirements, so that there's an additional set of requirements
(mainly around internal references) to make a "complete" or
"self-consistent" document.

For example, the linter doesn't currently complain about this
spectacular typo ("edat" for "edit"):

    <textarea name="content" form="edat"></textarea><form action="/"
method="POST" id="edit"></form>

Even though the spec says:

"If a form-associated element has a form attribute specified, then
that attribute's value must be the ID of a form element in the
element's owner Document."

http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fae-form

>From a developer perspective, not catching missing or broken internal
references like this is really annoying as it's the sort of thing I'd
expect a machine to detect easier than a human.

If we don't resolve this tension, linters will be a lot less useful in general.

>> http://www.w3.org/WAI.new/PF/aria/roles#namecalculation
>
> Spec writing that puts a point starting with "Authors MAY" under "The
> text alternative for a given node is computed as follows:" is
> sad-making. :-(

Yeah, I think that spec has been and remains problematic.

http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0049.html

http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0051.html

http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0052.html

http://lists.w3.org/Archives/Public/public-pfwg-comments/2012AprJun/0003.html

http://lists.w3.org/Archives/Public/public-pfwg-comments/2012AprJun/0004.html

http://lists.w3.org/Archives/Public/public-pfwg-comments/2012AprJun/0018.html

I've suggested to PFWG (0003.html) that "The [ARIA] host language
requirements should include requirements around defining precisely how
host language
features, if any, play a role in the calculation of accessible names
and descriptions: for example what host language features constitute
label association or tooltips for the purpose of this algorithm."

Browsers have to expose these accessible name and accessible
description fields to accessibility/automation APIs. Where are browser
standards folks turning to ensure interoperability here? Is there any
interest in adding spec text to address this in the Living Standard?
The other place we could work on this would be Steve's mapping guide
at HTML WG, but I don't know if that will track edge developments in
HTML.

--
Benjamin Hawkes-Lewis