Summary of TPAC 2021 Maps for HTML Community Group meeting for the SDW WG 2021-11-11 and subsequent discussion

Hello SDW WG,

Today's SDW WG meeting was postponed, so Jeremy asked if I could summarize the Maps for HTML community group meeting at TPAC 2021 [0], and the discussion that ensued [1], so that SDW WG members would be in a position to come to the next meeting prepared to further discuss and weigh in on the issues; I hope we can allocate some time next meeting to that discussion.  Also, please feel free to respond here if you have questions or prefer to discuss this way.

Community groups are formulated to "socialize ideas", so this meeting of the Maps for HTML Community Group represents a significant step forward in getting some Web Platform attention on the domain of Web mapping and location information on the Web. "Socialization of ideas" is a major imperative in Web standards development; because the Web serves all of humanity, we need to express ideas for standards in a way that serves the maximum number of users possible.  Often, user interface widgets are a relatively easy thing to discuss in this context, since many many websites use <select> and <input> and so on. Maps and location information have not, to date, been seen as a cross-cutting issue of the same order of importance or general relevance.  I started the Maps for HTML Community Group from the conviction that maps and location are very much a cross-cutting, societal-relevant issue worthy of consideration for adoption by the Web Platform itself.

Some key ideas that I put forward in my presentation [2]:

* at the joint W3C/OGC 2020 Workshop on Maps for the Web [10], we heard loud and clear from the Web accessibility community that most Web maps are inaccessible, and need to be standardized, with standard accessibility baked in.  This "baking in" process happens at the HTML level.
* since the workshop, we have worked mainly on accessibility features, including: screen reader support; links in maps to and from map information; accessible names for all features; differential styling of feature parts; accessible popups for feature metadata; map keyboard access and support; localization of map UI; screen reader announcing map location and zoom as the map view moves, and other items.

Simon Pieters, chief Web engineer of Bocoup and co-editor of the WHATWG HTML Standard reviewed the discussion of the issue that he raised with the WHATWG HTML steering group [4]. Some of the points that the WHATWG made are good suggestions, for example: the things that make it difficult to make Web maps accessible, and to inform our efforts from similar efforts such as that of the Open UI community group.  You can see from my presentation that the Maps for HTML CG have indeed been identifying and polyfilling those features of maps that tend to make them inaccessible.  Further, Maps4HTML CG admires the work of the Open UI community group, which is basing their Web Platform proposals for new / updated user interface widgets based on research of the major Web design systems and JavaScript frameworks for what are common patterns.  This is a very similar research methodology to that the Maps for HTML Community Group has followed in establishing our Use Cases and Requirements [7], for example, where we have based our declarative proposal for maps on existing behaviors supported by typical Web mapping platforms [9].  On the other hand, I get the sense, based on the (often-repeated) reference to "JavaScript primitives" from the Web Platform / WHATWG maintainers, that HTML is in fact NOT open to changes from communities such as our own.  This is really unfortunate!  It also stands in stark contrast to the reception that these organizations afford to HTML proposals from their own committee members.  For example, in September, the WebKit team proposed a new <model> element for HTML [5], which was quickly welcomed by the Chrome team [8]. Comparison of the <mapml-viewer> with the <model> proposal garnered some discussion among our CG meeting participants, and it was later suggested [6] that the <mapml-viewer> proposal could be simplified / split up, to be more like the <model> proposal.  This is worth some detailed discussion.

Satoru Takagi of W3C member KDDI updated the group on his work since the workshop to support map projections and quadtree vector tiles in the SVGMap.js Web mapping framework [3], which now includes a prototype custom element version of the library.

The meeting minutes [1] were kindly captured by Brian Kardell of W3C member Igalia, with help from Boaz Sender, CEO of W3C member Bocoup. These two companies are both very much involved in the ongoing evolution of the Web Platform; they have been involved in HTML, Web Platform Tests, MathML, MapML, SVG,  CSS, and lots of other Web platform developments.

[0] https://www.w3.org/community/maps4html/wiki/TPAC_2021_Agenda
[1] https://www.w3.org/2021/10/29-m4h-minutes.html - incomplete record due to my failure to appoint a scribe beforehand
[2] https://docs.google.com/presentation/d/1aApU0AmW_VlRGhi93rCBq-8IJ3LWRR6ZqvyzGgN1mms/edit?usp=sharing
[3] https://satakagi.github.io/mapsForWebWS2020-docs/update202110.html
[4] https://github.com/whatwg/html/issues/6380#issuecomment-872405399
[5] https://github.com/WebKit/explainers/tree/main/model
[6] https://discourse.wicg.io/t/updates-on-svgmap/5676
[7] https://maps4html.org/HTML-Map-Element-UseCases-Requirements/
[8] https://github.com/WebKit/explainers/issues/74
[9] https://maps4html.org/UCR-MapML-Matrix/mapml-ucrs-fulfillment-matrix.html
[10] https://www.w3.org/2020/maps/report



Peter Rushforth
Technology Advisor
Canada Centre for Mapping and Earth Observation
Natural Resources Canada