Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 25 11:33
    Malvoz edited #13
  • Apr 25 11:33
    Malvoz edited #13
  • Apr 04 12:08
    Malvoz edited #13
  • Jan 04 03:55
    Malvoz closed #20
  • Jan 04 03:54
    Malvoz closed #16
  • Dec 14 2021 08:51
    Malvoz edited #13
  • Dec 08 2021 02:33
    Malvoz edited #13
  • Dec 08 2021 02:27
    Malvoz edited #13
  • Nov 28 2021 03:53
    prushforth commented #19
  • Nov 28 2021 03:31
    Malvoz commented #19
  • Nov 28 2021 03:08
    prushforth commented #19
  • Nov 28 2021 02:52
    Malvoz commented #19
  • Nov 28 2021 02:40
    prushforth commented #19
  • Nov 28 2021 02:19
    prushforth commented #19
  • Nov 28 2021 02:16
    Malvoz commented #19
  • Nov 28 2021 01:40
    prushforth commented #19
  • Nov 28 2021 01:30
    Malvoz commented #19
  • Nov 22 2021 14:33
    dret removed as member
  • Nov 22 2021 14:11
    dret added as member
  • Nov 18 2021 20:52
    prushforth commented #21
Robert Linder
@Malvoz
Sounds good, I don't quite get the gist of it all yet. Just making sure, because we don't want to promote <map> too much. At least the web map docs has got a big warning: https://maps4html.org/web-map-doc/docs/maps/web-map/
Peter Rushforth
@prushforth
@erictheise @Malvoz I will be on holidays for a couple of weeks. My new team starts September 7th, but we'll take some time to ramp up, I think. It would be ideal to review if there will be items we can prioritize that will help accessibility needs, maybe have a chat the last week of August (>=30th). We will all be a bit green/rusty, so maybe we should start where we left off and fix problems, before we tackle new features.
Robert Linder
@Malvoz
I'm hoping accessible pan and zoom (Maps4HTML/Web-Map-Custom-Element#396) can be considered for the fall term milestone. It is tightly related to Feature Index, which is already on the list.
Enjoy your holidays Peter! :)
Peter Rushforth
@prushforth
:thumbsup: thanks!
Eric Theise
@erictheise
hope your holidays were pleasant.
I have a question for @Malvoz about the way stylesheets are called from tmpl.innerHTML in mapml-viewer.js.
Eric Theise
@erictheise
this approach doesn't seem to play well with a concat and minify approach, I haven't been able to get it working with webpack in our own build process and I wonder if it can be broken out in another way.
Peter Rushforth
@prushforth
Hey Eric, I think I came up with that mechanism. We needed to ensure that the map styles we import are scoped to the custom element/ module. Do you have another option?
Eric Theise
@erictheise
I'll look into it tonight.
Peter Rushforth
@prushforth
sounds good. Info: The import.meta was used so that we could use module-relative paths. The template literal is used to generate the DOM inside the shadow root.
Eric Theise
@erictheise
Also, there are 3 ReSpec errors in the spec currently. Wasn't obvious to me how to run that locally.
Peter Rushforth
@prushforth
Yeah it's been a while for me. @Malvoz may have some idea?
Peter Rushforth
@prushforth
Fixing those WebIDL errors now. Sorry, the spec has been neglected a bit.
Peter Rushforth
@prushforth
By me, only
Eric Theise
@erictheise
@prushforth is there an example anywhere of how to hand off a GeoJSON FeatureCollection to the CustomElement? feeling rather lost right now.
Peter Rushforth
@prushforth
We don't really support GeoJSON, actually. If you would like to do a hangout, maybe higher bandwidth might clear things up?
Eric Theise
@erictheise
sure, could we talk in about an hour?
Peter Rushforth
@prushforth
sure thing
Eric Theise
@erictheise
I need to eat something. Zoom okay? will send you an invite at the time.
Peter Rushforth
@prushforth
sounds good
Eric Theise
@erictheise
Peter Rushforth
@prushforth
@erictheise If you thought it might work for you, we could collaborate on a GeoJSONCollection2Layer function that could ship with the custom elements.
Peter Rushforth
@prushforth
It might be difficult to generalize how to output properties, apart from <featurcaption> I suppose.
Peter Rushforth
@prushforth
Although that part could be done by the caller and passed in as an argument.
Robert Linder
@Malvoz

the way stylesheets are called from tmpl.innerHTML in mapml-viewer.js

this approach doesn't seem to play well with a concat and minify approach

@erictheise I'm not experienced with these types of build processes, I don't think I can help with that. Ideally the 3 style sheets would be concatenated into 1 style sheet in the build process which would be called from tmpl.innerHTML, but that's just a performance optimization.

Also, note that the stylesheets are called the same way in web-map.js

Peter Rushforth
@prushforth
@ahmadayubi Yeah so we probably can't move the map on focus OR we can't sort on moveend. These could be mutually exclusive preferences, perhaps?
I think sorting on moveend is more important, because it's for non-visual users, whereas the move map on focus is primarily a visual thing, right?
Ahmad Ayubi
@ahmadayubi
It’s primarily visual but that is still related to accessibility, in terms of users who can see but can’t use the mouse. You could make it preferences. There’s 1 way you could merge the two: u can treat the moveend events caused by feature focus differently than moveend events from keyboard moves. This way once you start using tab the anchor was the initial location and you tab through the features from that initial location rather than recalculating distance on each tab.
Peter Rushforth
@prushforth
What I'm after is to give the user the knowledge of the closest thing to the centre (presumably them, or some feature of interest), by simple tabbing: the first element announced is the closest.
Ahmad Ayubi
@ahmadayubi
It’s a balance though, what benefit is it to focus the closest feature if the closest feature is off screen
I guess for screen readers it’s still valuable
Peter Rushforth
@prushforth
Usually that won't happen, since features are loaded by map extent, usually
Let's do one thing at a time: do the feature sorting. Then if the visual relevance is lacking, try to integrate move-on-focus with sort-on-move. Does that make sense?
Am I forgetting something though, the move-on-focus idea doesn't appear to be in our issues, had we just discussed it?
Ahmad Ayubi
@ahmadayubi
Yeah it’s issue #482, you added it to the fall term milestone, but that’s reasonable, we can do the sorting and figure out how to integrate pan on focus afterwards
Peter Rushforth
@prushforth
OK, that's Maps4HTML/Web-Map-Custom-Element#482. I think we can deal on this one, because the WCAG criterion is that the focus should be visible, not that the map should move. So, if there are offscreen features, we would have to move the map. Maybe instead of moving the map, we should detect if the features are offscreen and remove them from the tab order. wdyt?
Ahmad Ayubi
@ahmadayubi
That definitely works too
Maybe Robert can chime in on this, he would know more about the requirements details
Robert Linder
@Malvoz

The problem with removing offscreen features from the tab order is that it would be nearly impossible for non-visual users to discover them (I made a comment related to this for Leaflet, fwiw) - unless features that are panned/zoomed into view are announced.

There are many things to consider, that's why I opened both Maps4HTML/Web-Map-Custom-Element#396 and Maps4HTML/Web-Map-Custom-Element#397, which is only an attempt from me to describe https://github.com/Esri/a11y-map. If you navigate the demo map using a screen reader you'll find that it works almost perfectly (there are some bugs) for both visual and non-visual users.

Peter Rushforth
@prushforth
This demo map shows some nice pan / zoom / feature index characteristics, I agree. OTOH, the features that are visible do not seem to be in the tab order at all, so you need to use the feature index to happen across them, so it seems like a game of pin the tail on the donkey, to me. If I can see a feature that is important to the map (mostly trailheads / parks & rec in this case, I think), shouldn't I be able to navigate to it without knowing its name and searching for it (do I even know its name) or clicking on it, or hunting for it by squares? Further, the features that are not in the viewport, are they relevant? Aren't they like paragraphs of text that are not on my web site/page? Maybe important, but if they are, we link to them (not all web pages have all paragraphs, likewise, not all web maps have all the earth). Features that are in the DOM but not in the viewport are like paragraphs that are below the fold, though. Maps are mostly designed to avoid this, however, so the fact that they're out of the viewport seems to me to mean that they're static features i.e. from a file like our restaurants file, which is like the a11y-map demo dataset fwiw
Robert Linder
@Malvoz

OTOH, the features that are visible do not seem to be in the tab order at all, so you need to use the feature index to happen across them, so it seems like a game of pin the tail on the donkey, to me.

Perhaps feature index and conventional tabbing (although perhaps rather arrow keys, per Maps4HTML/Web-Map-Custom-Element#535) can/should co-exist as separate modes of navigation?

If I can see a feature that is important to the map (mostly trailheads / parks & rec in this case, I think), shouldn't I be able to navigate to it without knowing its name and searching for it (do I even know its name) or clicking on it, or hunting for it by squares?

Is this just a matter of highlighting (color/contrast)?

Further, the features that are not in the viewport, are they relevant?

When we view a map with our eyes, they aren't, so I don't see why they would be for a screen reader user, if that's what you're asking?

Peter Rushforth
@prushforth

Perhaps feature index and conventional tabbing (although perhaps rather arrow keys, per Maps4HTML/Web-Map-Custom-Element#535) can/should co-exist as separate modes of navigation?

That seems reasonable.

Is this just a matter of highlighting (color/contrast)?

I don't think so, but I could be wrong. If you zoom way out, you get all the accessible features they've got, which is a few dozen afaict, so seems to me that the only way to get at those features is through the feature index.

When we view a map with our eyes, they aren't, so I don't see why they would be for a screen reader user, if that's what you're asking?

Yeah I guess so. I think that the only way that features would go out completely of the viewport would be if they're static i.e. not prone to be reloaded when you pan or zoom, even. In that case I think it does make sense to pan to them if you focus on them. Maybe that can be accomplished as well as sorting per @ahmadayubi 's suggestion:

This way once you start using tab the anchor was the initial location and you tab through the features from that initial location rather than recalculating distance on each tab.

btw that Google Maps API arrow key navigation seems quite nice (unsurprisingly). The tab key cuts to the end/next control instead of moving between (many many many) features. The arrow keys substitute for tab to feature.
Robert Linder
@Malvoz
Robert Linder
@Malvoz
(some map libraries are among the offenders that have "the largest impact on the performance of the web as a whole")
Peter Rushforth
@prushforth
That's pretty interesting! I'm sure @zcorpan will be interested in the methodology. The number of occurrences is pretty important in establishing a 'cowpath', in particular.
Peter Rushforth
@prushforth
Even at a conservative estimate of 3-4% of all Web pages being counted as containing a map, that is significant, enough to constitute a paveable cowpath imho.
Youtube clocks in at 4%. video got its own element, so should maps lol.