Creating better instructions for how to label pedestrian signals

[jonfroehlich]

How many labels should I be applying here? It's not totally clear to me. Should I be labeling the "output posts" as well as the "input/button posts" in those cases when they are separate?

[jonfroehlich]

Here's the slide deck.

PedestrianSignals.pptx

[misaugstad]

Very good questions! We should continue to discuss with Yochai and Devon while working on the labeling guide!

[yeisenberg]

HI There, was looking for a good Ped signal and wanted to followup to add tags

• has crossing button
• button waist height
• has countdown light box
• has audible speaker (we need visuals of this)

---

As an update (Feb 21, 2024), we have long had:

• has button
• button waist height

[misaugstad]

A possible set of tags to get at the information we want, while also making it clearer to users how to label:

• 1 button
• 2 buttons (can't pick both)
• 1 walk light
• 2 walk lights (can't pick both)

We should iterate on the language for counting the number of directions for which a single pole has walk signal lights.

I do think that counting the number of buttons/lights on each corner will make this more clear for users, and will get us the information we want most of the time.

[yeisenberg]

This seems like a good direction to go. Also, got some feedback from a colleague that one key element to focus on could be whether the rater visually sees an arrow on the button and that this can be a good indicator in nearly all cases that this is an APS. He shared this link - https://polara.com/ids-ins. In the Chicago area, we see a ton that do not have this and that i've noticed don't seem to have the full APS capabilities of audio signals.

[yeisenberg]

In a training on new prowag and the key does seem to be that arrow. Would be great if we can add a tag that would indicate the button has an audio signal by seeing if there is that arrow:

[jonfroehlich]

Nice. Thanks Yochai!

[yeisenberg]

HI there, at our workshop, this was brought up as an important feature as we know. Thought I'd post again to restart this thrust to put the 'audio signal' tag as part of pedestrian signals that are key for people who are blind/low vision. thanks

[yeisenberg]

After some back and forth with Mikey on Slack am adding to this conversation. Based on that and this link related to new PROWAG - https://polara.com/guide/prowag-accessibility-requirements. Taking away from it
The discussion has to do with whether to have all 4 tags about the 1 or 2 buttons, or just the tactile button tagss? A key question is whether knowing about non-tactile-audio buttons is important?

• 1 button
  

• 2 buttons (can't pick both)
  

• 1 tactile-Audio button
• 2 tactile-Audio button (can't pick both)

• 1 walk light
  

• 2 walk lights (can't pick both)
  

• hard to reach button
• obstruction to pushing button

[jonfroehlich]

I think we should have:

• APS (with a nice hover image to explain)
• Walk light (again, nice hover image)
• Hard to reach button (if someone clicks this, does "has button" get auto-selected? or maybe we just deal with this in post-hoc analysis)

I'm not confident that having people count is a good idea; it also introduces ambiguity about the other tags. For example, if I put "2 buttons" then what do the other tags correspond to (e.g., button hard to reach, APS).

For a situation like this:

Should we ask folks to use four labels: one label for each walk light (two labels total) and one label for each button (two labels total)

[misaugstad]

@jonfroehlich and I talked a bit more after this. Here's what I think we settled on for the list of tags:

• has button (unchanged)
• button waist height (unchanged)
• APS (unchanged, but I need to unhide it) -- @yeisenberg lmk if you have a different preferred name for this tag
• hard to reach button (this is new, ideally have it auto-select "has button")

And then I need to add example images for all of them.

[yeisenberg]

Great discussion! Wondering though, since all the other labels have tags that would be considered 'negative' or 'missing' whether we should make all of these that way too.
Suggested approach:

• missing tactile-audible button
• button is too high
• button is hard to reach (maybe makes sense to combine with button is too high?)
• missing walk signal (haven't looked at Prowag but maybe we should to know if this required)

[misaugstad]

button is hard to reach (maybe makes sense to combine with button is too high?)

I really like that!

missing tactile-audible button

I think it's worth having this one in the positive instead of negative because of the knowledge required to know when this is missing. If users don't know what this means and therefore don't label it, we'd assume that all the pedestrian signal are tactile-audible, which I don't think is what we want. For now, I think I'd rather have people who know what they're doing choose to add a tag!

missing walk signal (haven't looked at Prowag but maybe we should to know if this required)

I think that we don't need to worry about adding this yet. What would it even look like to have a pedestrian signal without the walk signal? Just a button that doesn't do anything or only has sound?

So in summary, we're going with the following for now:

• has button (unchanged)
• tactile-audible button (changed from "APS", need to unhide it)
• hard to reach button (replacing "button waist height")

[yeisenberg]

Thanks for the updates Mikey!! For signals with two buttons, would we suggest that the auditor place two tags then?

[misaugstad]

I think that as of now, we are punting on figuring out whether there are one or two buttons. And when we do clustering, the two labels would be clustered together into only one anyway, so I think that we just add label even if there are multiple buttons!

[jonfroehlich]

It's funny, I was labeling the other day, and perhaps because this was top-of-mind, felt like it was relevant to have a "has two buttons" tag (but I still don't see how can operationalize that given that the other tags assume only one button like "missing tactile-audible button" and "button is too high"—those labels begin to break down when we have the "has two buttons" tag because it creates ambiguity). Hmm....

So that does just siggest having the auditor place two tags: one for each button.

[misaugstad]

IMO it would be better to have the ambiguity of not knowing which buttons are being referred to with the tags than it would be to train users to label the same pole multiple times because there are multiple buttons.

I'm basing that off the assumption that on a single pole it would be almost always be the case that both the buttons would have the same design. Not sure if others have a sense of how accurate that is.

[jonfroehlich]

True. I think you're right. (And, in practice, I've found that the same buttons are designed on the same pole...)

So, do we want to add "has two buttons" then?

[misaugstad]

I'd recommend replacing "has button" with "one button" and then adding a "two buttons" tag. And selecting one would automatically deselect the other.

[jonfroehlich]

Nice, yes! Thank you.

[misaugstad]

Great, so the new plan (switching from singular to plural for the other tags):

• one button
• two buttons (can't have this and "one button" selected)
• hard to reach buttons
• tactile-audible buttons (Chicago only)

This work for you @yeisenberg ?

[yeisenberg]

Looks good to me! what is the thought with Chicago only? like a testing phase?

[jonfroehlich]

I think we should deploy it everywhere (at least in US) Sent from phone

…

On Tue, Feb 27, 2024 at 8:37 AM yeisenberg ***@***.***> wrote: Looks good to me! what is the thought with Chicago only? like a testing phase? — Reply to this email directly, view it on GitHub <#3240 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAML55PPCGFECHPF2QYRMLLYVYDTPAVCNFSM6AAAAAAYMHUHQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRXGAZDGOBVGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[misaugstad]

That's fair, now that I've added an example image! 😁

[jonfroehlich]

Great, thanks Mikey!