API for adding aria-label with title content

[ndarilek]

I'm improving the accessibility of an app that uses the title attribute on a bunch of icon-only links, and unfortunately I can't think of a clean way to pull it off. It makes sense for the title attribute to be present since the links are icon-only, but titles are inconsistently presented by screen readers. Far better would be to include an aria-label as well, but the titles are often generated conditionally, so for many links I'd have to:

• Duplicate the title calculation code in the aria-label definition or
• Extract the title calculation to a separate variable/function and use it twice

Neither is a nice solution.

I propose an API that combs through the page and duplicates any title attributes it finds onto any elements without text's aria-labels. I suppose this could be a bit complicated since what an element's text is differs. Perhaps it could initially work for links, replacing any without innerHtml with an aria-label containing the value of their title. Links seem to be the biggest offenders.

I don't know what this API might look like, but I wonder if implementing it as a MutationObserver might work? Then it would automatically react on document changes.

[rodneyrehm]

Extract the title calculation to a separate variable/function and use it twice

Working with small components makes sense. If something can be extracted into a function (made more generic and reusable), do it.

I propose an API that combs through the page and duplicates any title attributes it finds onto any elements without text's aria-labels.

If I understand you correctly, you would like to enhance semantics by doing the following (using jQuery notation for brevity):

$('a[title]').each(function() {
  var $a = $(this);
  if (!$a.attr('href')) {
    return;
  }
  if ($a.text().trim()) {
    return;
  }
  if ($a.attr('aria-label').trim()) {
    return;
  }

  $a.attr('aria-label', $a.attr('title'));
});

While I'm sceptical about the proposed enhancements, we are thinking about adding features along this line in #69.

[marcysutton]

This issue comes up a lot....we did some enforcement of labeling in Angular Material by attempting to create an aria-label from text (applicable to custom form controls which require some kind of label as opposed to regular textContent). If there is no text to copy, the utility logs a warning to the console. There are tons of edge cases, though, and it still needs support for aria-labelledby.

$mdAria Service:
https://github.com/angular/material/blob/master/src/core/services/aria/aria.js#L22

mdCheckbox Usage:
https://github.com/angular/material/blob/master/src/components/checkbox/checkbox.js#L100

There is definitely precedent for the usefulness of an automatic labeling API. I'm also revisiting the same problem now on Coral UI. One big thing we still have to solve in that framework is internationalization: making sure text labels support multiple languages. Just wanted to point that out as something to consider.

[rodneyrehm]

I guess we need to discuss the scope of features we want ally.js to cover. In the "first wave" I'd like to support people who already know what they're doing by making things simpler for them. The SVG accessibility improvements pointed out in #69 do not do anything magic. They simply reinforce existing or easily inferable things. They don't guess. As soon as we start guessing, we're opening a can of worms I'd rather leave closed. After talking to you at btconf I understood that the guesswork done by ngAria is helping in some situations and causing trouble in others. I'd rather not jump into the same rabbit hole. At least not before everything else the library is supposed to do works reliably.

If we can populate the aria-label attribute with any (or very little) guessing involved, let's have a go at it. @marcysutton is the "reinforcing semantics" topic something you'd like to investigate?

[marcysutton]

Yes–I'd like to avoid guesswork as well. We should outline specific use cases and try to learn from previous implementations so this library doesn't make the same mistakes. What gave Angular tough gaps to fill were things like custom tags (with attributes sometimes copied over to native elements), component APIs written by different developers, ng-click being encouraged on any element, and poor accessibility in docs. If some of these issues can be fixed with better documentation or an audit tool, that's okay with me. :)