Create a map-extent checked attribute

[prushforth]

Currently, there is no checked attribute for a <map-extent>, yet the extent is checkable in the layer control if it has a label attribute. Even though there is currently no custom element for <map-extent> we should enable such a boolean attribute in preparation for creating a custom element version. The checked attribute would in this case control the initial state of the extent when loaded and first displayed.

Some issues that we may encounter:

• basically no single-extent layers that we've created so far have a checked attribute, so we would have to go back and add a checked attribute for them to be on by default. In other words, a backwards-incompatibilty with existing content

• only <map-extent> elements that have a label attribute are exposed in the layer control, so if an unlabeled extent has its opacity="0" then checking / unchecking the layer will have no visual effect on the map, which could be hella confusing.

• for the latter issue, we could either change the behavior of the layer control to show those unlabeled extents anyway OR we could devise a rule whereby unlabeled extents with an opacity attribute are shown / have a label generated so that they're shown.

[prushforth]

As far as a checked attribute goes, I think we should define that an unlabeled extent is checked at page load (generate the attribute). I note that actual <input type=checkbox ... checked> inputs don't actually change the value of thechecked attribute as the user updates them; only the .checked property changes. An extent with a label attribute is exposed in the layer control and should thus be under the explicit control of the author, who wishes it to be exposed, so no checked attribute should be generated for labeled extents. We will have to go back and change all examples with labeled extents to include the checked attribute. We should make an example of a labeled extent with no checked attribute to explicitly demonstrate the rule. This behaviour should be specified, and described in the spec.

[prushforth]

We have been working on the <map-extent> custom element implementation. (experiment). The checked attribute is a thorny issue: are we violating this a11y principle by designing nested interactive elements into MapML? How can we avoid / mitigate this? (The <map-extent> element is a nested child or shadow DOM descendant of <layer->, which also has a checked attribute, so they're both interactive, and nested).

The intent here is not to nest a button inside a button, or similar accessibility trap, but to represent interactive controls for map content in a form-like manner using their declared structure (nesting and attributes).

Currently, we have not documented the checked attribute of the <map-extent> element, but if it's to be checkable (as it currently is in the layer control layer settings), I believe it should have the possibility of a checked attribute, per spec (maybe/probably the spec needs change too).

Thanks for any thoughts you may have on this.

cc @Malvoz @AmeliaBR @shepazu @nchan0154

[nchan0154]

@prushforth
This is definitely very tricky! I feel like it's one of those things where the implementation really determines whether or not you've violated the 'no nested interactive controls' rule. In the working example, care has been taken to make sure none of the controls are actually nested and that it does work with the keyboard, but I wonder if the component is 'doing too much'. The control is complex enough that it simultaneously resembles a tree view as well as a <details> + <summary> element but there are additional form inputs nested within the view, and because of that it doesn't map neatly to either set of semantics. There is also mouse drag and drop that doesn't appear to be implemented for the keyboard, but adding it would muddy the waters further. The map-extent element itself being the one to have all these attributes may be confusing, especially for screen reader users. It seems also that since layer is check-able, by having map-inputs as a child of layer, it's already violating the principle? I'm not too familiar with the spec aspect (ie. if any other controls have this level of functionality in a single control, or if it's common for 'subcontrols' to determine a parents state), but I think now would be a good time to do some testing with/solicit feedback from a wider population.

Some questions/other thoughts I had when looking at the experiment that are worth considering from an accessibility perspective:

• The use of hover to open the layers control makes the drag and drop very particular, it's easy for the action to get interrupted by the mouse leaving the bounds of the window
• There are currently 3 controls that have slightly different, but similar functions of 'hiding a layer' (ie. toggling visibility, complete removal, opacity). Do we need all 3? My gut feeling is that removing a layer is the least useful here and getting rid of that control could simplify the UI, but perhaps there are use cases I haven't considered?
• Does each layer control need to be it's own disclosure widget? In the example, it feels like there is enough room to have both input and label be shown without the need for a disclosure widget.
• This blog post is food for thought

[prushforth]

@nchan0154 thanks for your thoughtful review. I appreciate that it takes a lot of time to delve into these things enough to comment clearly. And you've done that, so thank you. Taking these thoughts not necessarily in order:

@prushforth This is definitely very tricky! I feel like it's one of those things where the implementation really determines whether or not you've violated the 'no nested interactive controls' rule. In the working example, care has been taken to make sure none of the controls are actually nested and that it does work with the keyboard, but I wonder if the component is 'doing too much'.

Quite possibly! Yes, there's the rule, and the spirit of the rule, and I think we've walked a fine line to not violate the rule, but we are challenged to design a default layer control that lives up to the spirit of the rule. I am trying to picture the default layer control as one possible "projection" or "view" of the map content, with the actual map being another such perspective. As such the layer control MUST be pretty darn accessible, and usable. Not sure we're there yet, as you suggest,

now would be a good time to do some testing with/solicit feedback from a wider population.

and I agree a wider review would be good now. I will try to engage W3C members to that end.

There is also mouse drag and drop that doesn't appear to be implemented for the keyboard, but adding it would muddy the waters further.

Yes, probably so. OTOH, I have always wanted to implement keyboard drag and drop for it, but I don't know how, or if it's even possible. If implementing keyboard drag and drop is not possible, it should not become part of the proposal, but the feature is currently useful for demonstrating the DOM api that is implemented by the <mapml-viewer>, <layer-> and <map-extent> elements.

The map-extent element itself being the one to have all these attributes may be confusing, especially for screen reader users. It seems also that since layer is check-able, by having map-inputs as a child of layer, it's already violating the principle?

<map-extent> started out life without the interactive attributes, and for a while I tried to keep it in that box, first by saying there could be only one <map-extent> per layer, and then when it became clear that enforcing such a rule might be counter-productive, by saying that if <layer-> contained only one <map-extent>, that the lone <map-extent> would be hidden by default in the layer control, because of course you could check and uncheck the <layer->, so adding controls to the extent would be complicated and redundant.

The map-extent element itself being the one to have all these attributes may be confusing, especially for screen reader users.

As we are implementing the <map-extent> custom element now, we need to implement defined semantics and so having checked, hidden, label attributes behave according to some written down specs is vital. The (albeit slightly fuzzy) plan is to implement "automatic layer (/extent) selection for non-visual users via user preferences expressed as CSS media query(-like) rules".

I agree that even for non-screen reader users, the complexity of the layer control interface, especially with sub-layers (map-extent) is annoying and concerning.

The control is complex enough that it simultaneously resembles a tree view as well as a <details> + <summary> element but there are additional form inputs nested within the view, and because of that it doesn't map neatly to either set of semantics. There is also mouse drag and drop that doesn't appear to be implemented for the keyboard, but adding it would muddy the waters further. The map-extent element itself being the one to have all these attributes may be confusing, especially for screen reader users. It seems also that since layer is check-able, by having map-inputs as a child of layer, it's already violating the principle? I'm not too familiar with the spec aspect (ie. if any other controls have this level of functionality in a single control, or if it's common for 'subcontrols' to determine a parents state), but I think now would be a good time to do some testing with/solicit feedback from a wider population.

Some questions/other thoughts I had when looking at the experiment that are worth considering from an accessibility perspective:

• The use of hover to open the layers control makes the drag and drop very particular, it's easy for the action to get interrupted by the mouse leaving the bounds of the window

Yes, I hate it too.

• There are currently 3 controls that have slightly different, but similar functions of 'hiding a layer' (ie. toggling visibility, complete removal, opacity). Do we need all 3? My gut feeling is that removing a layer is the least useful here and getting rid of that control could simplify the UI, but perhaps there are use cases I haven't considered?

As mentioned earlier, I think it's useful for demonstrating the DOM api that comes with the custom elements, but good point even removing minimally useful controls simplifies the UI and improves the usability.

• Does each layer control need to be it's own disclosure widget? In the example, it feels like there is enough room to have both input and label be shown without the need for a disclosure widget.

Do you mean the three dot / 'hamburger' menu button? I think the opacity control is a requirement, but it's good to not have it in your face all the time. And we are currently nesting <map-extent>s inside that as well, so it would be a lot of (possibly not relevant) stuff to go through for a keyboard user, for example, if we didn't use the disclosure approach.

• This blog post is food for thought

Thanks, will read.

[yhy0217]

Resolved to #887, horizontal review from W3C accessibility community is required.