Meeting minutes
<boaz> I'm interested in talking about adding a geospatial mapping pattern to APG, if there's time left at the end of the agenda, do you think we could add that?
Agenda changes?
<Jem> https://
Jem: we can add that to the agenda Boaz. Our next meeting will be 8/30.
Jem: any updates on the repo restructure?
update on repo restructuring
Rich_Noah: we're a bit ahead of schedule. alex got the work done on regression tests, matt had his feedback addressed
Rich_Noah: alex is progressing through next steps and we'll check in on it later this week
<Jem> https://
matt_king: Glad to know there won't be duplication in anything from github
<Jem> https://
matt_king: there's a question about merging Jon's skipTo that I have to review
<Jem> https://
matt_king: I'll make it a priority to review 2402 and hopefully elimination of jump to
alexander_flenniken: that'd work great, sounds good
matt_king: once we figure out what we need to do to stop pushing main to gh pages, we can start working on manual changes to gh pages branch
… if we want to point people to the new locations AFTER 2417 is merged, we should prepare those changes and PR them against gh-pages, merging them after after merging 2417
… we'll have to update that branch quite a few times as we work on this.
… not sure it's possible to do actual redirects, might just be a "404" type of landing page
alexander_flenniken: we figured out the contact for redirections --
matt_king: but these are gh pages. those can be redirected?
alexander_flenniken: oh okay, no I was talking about the previous live site
… but I *think* we could redirect those too
… maybe the expectation is to see a preview of some kind, so it's less disorienting to jump to a new site etc
Jem: it's kind of confusing how things are working, could we have a simpler workflow somewhere?
… since we're pushing our changes to the WAI repo, I'm not exactly sure what that process is like, and as a group I don't think we have a lot of information about it
… when will this all be done?
matt_king: not sure yet, but moving as fast as we can
Jem: ballpark?
Rich_Noah: we looked at a total of about 8 weeks, since Bocoup does 4-day billing
Rich_Noah: so maybe the week of 9/19
Jem: after TPAC then. and after THAT we'll go back to our normal workflow
matt_king: we're a little ahead of schedule though right Rich?
Rich_Noah: yeah, but I haven't shifted anything yet. i don't really think we'll have reduced any overall time
Jem: so what's on gh-pages?
matt_king: the editor's draft - that's drafted and created from the gh-pages branch, and that's what we want to shut down
matt_king: we either want a redirect from here -- but that might be shocking since it's on a new domain -- or we'd replace that page with a "404" and guide people to the new location
Jem: doesn't MichaelC do that?
matt_king: they do for TR, *we* handle the editor's draft
matt_king: we could try to mimic what's done for TR, but it feels a little complicated
matt_king: maybe we'll take that content from their modal and put it on the pages generated from gh-pages
matt_king: so what's our decision/resolution?
… a browser redirect? or a "404" redirect?
alexander_flenniken: do we intend to replace this gh-pages branch in the future or deprecated forever?
matt_king: the latter
alexander_flenniken: could we leave the content and add a note?
matt_king: we're trying to remove all old content so people don't use it by mistake
s3ththompson: maybe that's a vote in favor of replicating TR though?
matt_king: truncating the content down to a warning, then?
s3ththompson: but the warning would be a modal
matt_king: that feels a bit unnecessarily complicated
s3ththompson: maybe we take an action item to find the most efficient way to do it? maybe actually just copying what TR does?
matt_king: I think the problem with the TR site is it still retains some content. we do that THERE because of the W3C process, which doesn't apply here
Jem: i think Matt is leaning towards removing the whole page because APG is a note not spec
s3ththompson: so we're leaning toward a redirect?
matt_king: well the content of the modal
jamesn: why not just straight redirect it? it's an editors draft, it's subject to change at any time
s3ththompson: it might be most efficient just to do a plain redirect
jamesn: or if we DO do any sort of "this content doesn't live here" page, just leave it at that. no need for fancy modals etc
jamesn: people usually just want the information they want as soon as possible, so let's just redirect them and get them there as soon as possible
s3ththompson: would be the most efficient implementation
matt_king: and the most efficient review
matt_king: there's our decision. redirect for gh-pages, and restructuring is a bit ahead of schedule, done around TPAC time.
Adding a pattern to APG
boaz: i'm interested in contributing as an author, and i'm interested in working on a geospatial map pattern. is that out of scope, or how might I be able to go forward with that?
boaz: been working on a prototype with a plugin, and seems like it'd be a good conversation to have with APG
Jem: what's the component of the geospatial pattern? a 3D library, etc.?
boaz: right now the scope of the prototype is a 2D square. we generate text descriptions of what's on the map, and relate it to cardinal directions
boaz: hypothesis is we can represent graphical geospatial maps as a text/keyboard interface
Matt_King: thinking about what roles to use for the elements... could be some interesting use of either/both application-role and role-description
Matt_King: we have no valid uses of application-role at the moment, but that might be a good use for it.
Matt_King: there's a possibility of having a good reason to use role-description, if there's objects like building, road, bridge. those could be individual elements
boaz: trying to come up with a fully interactive, text equivalent of a Google Maps- style map
boaz: we need to think about how to better incorporate panning and zooming types of behaviors too
Matt_King: so is it like marking points?
boaz: yes, marking points and describing their relationship to each other
boaz: tl;dr - is this offbase for APG or is this a good place to discuss? should I start smaller?
jamesn: there's so much that COULD be done with geospatial maps, but i'm not sure we're ready for this in APG. data viz is a "smaller" amount of information, but it's still very complicated
boaz: would you like information about accessible data viz?
jamesn: people have been working on that for ages and not gotten very far, it's hard!
Matt_King: if you're willing to work on things, do it in a format that's good for APG, and put in all that work - as well as educate others - we COULD be ready for that
Matt_King: if there's specific problems ARIA *can* solve now, then let's work on it.
Matt_King: maybe a matter of using functional, reusable patterns that can *reduce* your work.
Matt_King: especially if this can help cover gaps in APG, that could be very helpful. but it's a matter of being willing to spend the time on it
boaz: that's what I'm talking about. I have internal tools to work with these prototypes, but I'd love to make them more reusable, like you say about APG patterns. definitely want to take the time to do so if APG would have me
Jem: i see that this probably isn't too far off from what i'm working on too
Jem: we've been thinking about how to make it accessible with omething like grid or table patterns. i could see this being useful for any project that's going to involve maps
Matt_King: i think it's worth experimenting with if you have the time and appetite Boaz
boaz: i'm hungry and in no rush :)
Matt_King: if we talk about maybe one meeting per month and we can come up with things people can actually use, that'd be great. just make sure to have patience and realistic scoping
boaz: absolutely! is there someone I could talk to about the gaps I could address with this project? i'd want to make it as useful as possible
Jem: thank you Boaz!
boaz: what's the best next step?
Matt_King: an issue
jamesn: you might be surprised that there's ltos of others interested :)
New issue action planning
Jem: 17 issues are still open
<Jem> https://
Matt_King: i'm not sure what the best solution to this is Siri
Siri: it doesn't seem like each screen reader reads everything as a table, but some of that has been discussed in the other issues linked in 2439
Siri: it seems like, if there's a long table/grid, and maybe someone using a magnifier, it might be confusing to know that I have to scroll up to see items in the grid, or if I am on item 14 and tab out, I would think I'd go back to item 14
Matt_King: if you have a situation where grid doesn't work well, then don't use that example. so like in toolbar, we recommend remembering the last position of focus, though it's not a default. for all composite elements, that remembering of position is a design decision
Matt_King: not a requirement
Matt_King: well not even "requirement," -- it's not a fundamental aspect of the pattern
Matt_King: i'd say losing your place in most grids or long lists it can be frustrating, so that can help
Matt_King: is the heart of the question if the grid should remember the last item focused?
Siri: yes
Matt_King: it might be unusual, but it is a design decision. there might be scenarios where you don't want to, but if there's a case where it's best for the user then that's what you want to do
Matt_King: I also don't understand your last statement about screen reader users getting lost
Siri: if there's a long list of items, removing anything in the middle could cause someone to get lost
Matt_King: so if you have 1000 emails, and you delete 500, the item that was previously 501 gets focused. so this way you can just keep delete delete deleting etc.
Siri: right, and while I'm in it that's fine. but if I leave that element and come back, that can be when I get lost
Matt_King: right, but it remembering where you were is meant to help you not get disoriented
+1
Jem: what would we like to do with this issue? we're at time
Siri: if anyone has an opinion can put it in the issue, that would be great for me
matt_king: we will continue discussion of Siri's issue asynchrounsly.