Btukfyl

I am currently trying to make a more accessible version of an info window by extending google map's overlay view class (by building on this example). In my web app, when the user clicks on a marker or on an item in a list of locations displayed in a sidebar, an info window will open up at the position of the corresponding marker and display supplementary information about the selected location, which may include a description, images, ratings, tips, etc. retrieved from another API. There will only ever be a maximum of one info window open at any given time.

What I'm confused about is which semantic element or role attribute or whatnot to use to describe the info window and thus how to manage focus accordingly? My current thoughts are:

1. use the role = 'dialog' attribute and develop the info window as a non-modal type dialog so that external content outside the info window is still accessible. In this case, the marker and list items can have the attribute aria-haspopup = 'dialog' which would nicely alert of the opening of the info window. The problem with this approach is that it is disruptive by nature and it's not exactly critical information being displayed in the info window nor is it information in which the user needs to respond to it.


2. use an <aside> element since it contains information complementary to the marker or side bar list item clicked upon. The info window will have a title of the location clicked on, so the info window could be viewed as stand alone information. However, I can't use the aria-haspopup attribute in this case. I suppose I could label the marker and list item buttons in such a way as to alert the user that an info window will open up as a result by using aria-label.


3. use role = 'tooltip' and describe the info window as a tooltip widget. But this implies that focus has to be trapped within the info window until it is closed. In google map's actual implementation of the info window, a user can interact with anything else on the page without focusing the info window to close and I don't think it makes sense to change that default behavior. There's also arguments about whether a tooltip can be triggered outside of a mouseover/hover event and I want the info window to appear on a click event or enter/space key events.


4. implement the info window as 'collapsible content' and the associated marker and list item buttons as 'disclosure' buttons. This way the user is alerted of extra content appearing in a non-disruptive manner and focus isn't trapped within the info window. Although the styling wouldn't follow the typical styling practices/DOM order of collapsible content since the info window's html wouldn't appear immediately after the html of the button that triggered the info window opening.

Which option(s) is appropriate, or is there a better approach that makes more sense?

Depending on which approach is chosen, should focus be trapped within the info window?
If the info window is closed and the focused wasn't trapped within the info window, where should focus go after closing it using a click event or keyboard shortcut:

1. The button that opened the info window?


2. The last focused element before closing the info window (provided the last focused element was outside the info window)? But what if the last focused element was an element within the info window?


3. The body element or map element?

Also, should focus move immediately into the info window when it is opened or should it remain on the button that triggered it's opening?