osm-americana / openstreetmap-americana

A quintessentially American map style
https://americanamap.org
Creative Commons Zero v1.0 Universal
183 stars 60 forks source link

Document accessibility goals and features #743

Open quincylvania opened 1 year ago

quincylvania commented 1 year ago

Accessibility should be a fundamental consideration for any widely-distributed software, but it can be easy to sideline. When I worked on iD, I started a document cataloging the app's compatibility with different systems and its usability by people with different abilities and backgrounds. The doc drove development by identifying major holes in usability that had gone unnoticed by devs for years.

Americana is already pushing the state of the art for OSM map tiles with inclusive features like dynamic multilingual labels. I propose we keep the energy going and set clear goals for accessibility. This would help new contributors and aid in decision-making, similar to #385.

Some general ideas:

I can see Americana one day becoming a standard-bearer for OSM cartography and ending up in all sorts of places we can't imagine yet. Thinking about this stuff now puts us on stronger footing going forward.

1ec5 commented 1 year ago

Multilingual support – text should adapt to the user's browser languages (doing great on this already, keep it up!)

Tracking the rest of the UI in #744.

High-contrast – overlapping colors should be easily distinguishable (might require an alternate color scheme to satisfy all cases)

We don’t make much use of fill patterns yet, but they can be very useful for minimizing the number of colors we rely on to communicate characteristics about a feature. We do use line dash patterns, but the lack of data-driven styling for dash patterns makes it difficult to scale these treatments to more features: maplibre/maplibre-gl-js#1235.

High-contrast – overlapping colors should be easily distinguishable (might require an alternate color scheme to satisfy all cases)

I think this is a worthy goal even with the current design motif. Currently, Americana has much better contrast than openstreetmap-carto in well-mapped areas. To keep up that contrast, we would need to be very selective about the kinds of fills we introduce to the style. In my opinion, this is an argument for leaving out many of the physical geography distinctions that openstreetmap-carto makes – good grist for a more topographic-oriented “layer” that this application could perhaps switch to dynamically.

Dark mode - light-on-dark alternative style (yes, this is designing an entire second color scheme; might be a longer-term idea)

Some users also like dark mode for aesthetic or ergonomic reasons. There isn’t much precedent for this in our usual design sources, other than turning off the passenger-side overhead reading light. But if we can get away with only making the style slightly darker, not quite based around a black background, then I think this is quite feasible. I even have some print maps in my collection that have fairly dark gray or brown backgrounds and even darker water. These maps don’t overwhelm the eyes, but the amount of ink they use probably isn’t very environmentally friendly either. 😅

Scalable font sizes – users should be able to make labels bigger while the map zoom remains the same (most browsers have a text-only zoom feature we can follow)

text-size-adjust looks useful for the overall UI. Is there a DOM equivalent that we can feed to the style and use directly in the shield generation code? (Related: mapbox/mapbox-gl-native#7030.)

Cross-browser support – always an uphill battle, would be nice to automate tests somehow

We could use some help on this front. We’ve been managing so far by sticking to conservative dependency choices and maximizing our use of these dependencies rather than rolling our own UI, but eventually we’ll probably run into browser compatibility challenges like any other project.

Low-performance devices - should be usable on old hardware and with slow internet connections

This is our greatest challenge as we push the boundaries of what’s possible in the styling language. As we profile the style’s performance, improvement could be upstreamed to the dependencies to make our use case more achievable on lower-end devices.

1ec5 commented 1 year ago

It’s worth mentioning that Mapbox made a plugin to integrate GL JS with screen readers. mapbox-gl-accessibility is no longer maintained, but it points to how a GL JS map could be made more ergonomic to those with visual impairment. Much of what differentiates Americana from other OSM-based renderers is visual; however, our choice of vector tiles does make the map more readily accessible than raster styles like openstreetmap-carto, as the dynamic legend demonstrates. We would have to find an alternative to hacks like https://github.com/ZeLonewolf/openstreetmap-americana/pull/592#discussion_r1035291368.

1ec5 commented 1 year ago

I forgot this issue was about documenting the current status. 😅 Yes, we can document the status of accessibility support, though I’d recommend using GitHub’s various project management tools to track this work more efficiently. We have https://github.com/ZeLonewolf/openstreetmap-americana/labels/internationalization and https://github.com/ZeLonewolf/openstreetmap-americana/labels/performance for a couple of the points above, and now https://github.com/ZeLonewolf/openstreetmap-americana/labels/accessibility for the rest. Once we collect the requirements in individual issues, we can track them in a project board. We did something similar with shield internationalization, using a project and https://github.com/ZeLonewolf/openstreetmap-americana/labels/internationalization to track individual to-do items but a map in the readme to garner enthusiasm for the initiative.

For now, I think this epic does a great job of setting context. The FAQ on the wiki is still a rough draft but could use some accessibility-related content too.

quincylvania commented 1 year ago

I forgot this issue was about documenting the current status. 😅

@1ec5 The first step is discussing what's possible and desirable! Your thoughts are great.

I'm all for tracking this work in issues, but I still think we should have a living document that outlines what's supported, what's not, and what support we want to add or maintain. This could be on the wiki, in a markdown file in the repo, or just a section of the readme. I can draft the content if no one beats me to it. (I didn't even realize this project had wiki pages… we should probably link them from the readme if they're notable.)

1ec5 commented 1 year ago

I didn't even realize this project had wiki pages… we should probably link them from the readme if they're notable.

That’s the plan – we just haven’t fleshed out enough of the FAQ to be very informative yet.