Would have preferred <details> and <summary> usage for the buttons to expand restaurant information

[prushforth]

The JAWS screen reader user reported a concern about the expand/collapse buttons used for the restaurant details. The user identified that these buttons should have ideally been implemented with HTML native <details> and <summary> tags.

The <details> and <summary> tags are used to create an "accordion" functionality, which comes with all necessary JavaScript and ARIA roles for a screen reader to recognize and announce state changes in these elements, especially transitions between "collapsed" and "expanded" states.

The user said, "So if you use those summary details panels that come with the HTML system and you don't modify the ARIA roles in any way, the button will be activated in browse mode and it will report its state when it becomes activated. If you activate it again, it will report the change from expanded to collapsed." It seems that the built-in features of the HTML system are well-configured for accessibility.

Conversely, the current custom-made interaction buttons hinder effective navigation, requiring double pressing to trigger their actions. The user suspects an unwarranted application identifier resulting in this unexpected behavior: "I'm guessing they've put some sort of application identifier on that button that shouldn't be there."

Additionally, the issue exacerbates for those having automatic forms mode enabled in their screen readers, leading to an unreliable user experience. The user mentions, "Furthermore, if you have automatic forms mode turned on in your screen reader, it makes things even worse."

[prushforth]

Need to evaluate how forms vs browse mode affects feature interaction. I think part of the issue may be that geographic features or locations are being "modelled" as buttons in this html simulation of a map, and there needs to be the notion of a feature that can be interacted with. Of course we are leveraging expanded and collapsed here, and how that relates to a geographic feature needs to be clarified.

Also, we are considering providing a "prefers table" approach that would interpret the map as a table and each feature or location in the map as a row in the table. In such a situation, the details/summary approach would work VERY well.