Features should have accessible names for discernability

[Malvoz]

The features are indistinguishable to someone relying on a screen reader as they don't have an accessible name. <path tabindex="0"> is announced as graphic in Chrome (blank in Firefox):

Keyboard.Interaction.Test.-.Google.Chrome.2021-02-01.01-37-.mp4

Originally posted by @Malvoz in #270 (comment)

[Malvoz]

I see that the <path> element supports a child <title> element that provides an accessible name. If we can come up with a convention for providing a similar accessible name for <feature>, we could generate the <path><title> from it.

Originally posted by @prushforth in #270 (comment)

[Malvoz]

Given the extremely generic properties model that <feature> has, I wonder if we should add a <title> element child of <properties> as a special case for accessible names purposes similar to svg. In the polyfill we can map that to <title> or what have you. I'll open an issue on this latter discussion in the MapML and UCR document repos.

Originally posted by @prushforth in #270 (comment)

[prushforth]

I believe that title is a global HTML attribute, so maybe it makes sense to respect / use a <feature title> as an accessible name. We don't have to worry about conflicts between a <title> and <feature title>.

[Malvoz]

In that case we should consider label as opposed to title.

[Malvoz]

label is element-specific per element's definitions, and more encouraging for authors to use as opposed to title which feels more "optional" since it's a global. title also implies the native tooltip on hover.

[prushforth]

A little googling on the title attribute reveals it is considered an accessibility problem. So scratch that proposal.

[prushforth]

This is resolved by opting for a <feature><featurecaption> element for the moment.