search

mmiron-HC / WST-RSAMS

0 stars 0 forks source link

Build-AUDIENCE: checkbox label contains dash #142

Open XiuJuanXia opened 2 years ago

XiuJuanXia commented 2 years ago

URL: https://rsams.dev.cloud.openplus.ca/en/node/64019/edit?display=section_1&destination=/en/node/64019/build User Agent: Chrome (v99), Firefox (v98) Language: Both

Issue Description: In the "AUDIENCE", there are a list of checkboxes. Some of the labels of the checkboxes starts with a dash. image

Steps to reproduce:

  1. Login as an admin: https://rsams.dev.cloud.openplus.ca/en/user/login
  2. Activate "Build"
  3. Edit "Section 1 - Summary"
  4. Navigate to "AUDIENCE", and label for checkboxes starts with a dash.

Expected results: Checkbox label should not start with a dash.

echouin commented 2 years ago

@XiuJuanXia this is working as intended. The - are sub-categories that we now have available to users.

XiuJuanXia commented 2 years ago

@echouin If the dash are sub-categories, this becomes a WCAG issue. Because nobody knows this is sub-category - neither sighted users nor non-sighted users. I updated the labels.

davidgotlieb commented 2 years ago

@XiuJuanXia Can I better understand why this is considered Critical failure? This seems like a pretty minor issue to me?

XiuJuanXia commented 2 years ago

@davidgotlieb It is critical as this isn't not being conveyed to anyone. If you feel this is a lower risk you can explain it when it goes to the CIO.

davidgotlieb commented 2 years ago

@XiuJuanXia @mmiron-HC But what's the impact of it? Shouldn't the severity be tied to how it would impact accessibility etc.? Isn't that the whole point of marking them with severity tags, so we can focus on the ones that will be a barrier to people using the site properly?

From a user perspective, they will check off the audiences that apply to the recall when doing data entry. Having a dash or not won't have any impact on their ability to do that, nor will it confuse them. So I just don't understand how this is a critical issue. To me this is at most moderate, when I compare it to some of the other items.

mmiron-HC commented 2 years ago

as per our discussion, While we, WST, have agreed that this is not considered critical, we disagree that this is lower than a serious. We have discussed this at length and have agreed to disagree.

davidgotlieb commented 2 years ago

Hi @mmiron-HC ,

Given that we don't have any development time right now, I asked OP if there were any quick configuration solutions to this issue.

They have changed the config in the dev environment to use dropdowns, which has a clearer delineation for the sub categories, but to be honest I think is an even worse user experience, and will also be much more time consuming to use.

Would something like this address your concern? Anything else would require them to do custom code.

image

mmiron-HC commented 2 years ago

@davidgotlieb without really looking at it we can't tell 100% but we do feel just by looking at it that it isn't a great solution. We will have more time to look at it next week.

davidgotlieb commented 2 years ago

I've put this on the list of things we'll look at for the additional 2 sprints we've added, will see what can be done but I think this should be lower priority than some of the other serious items that have been flagged.

davidgotlieb commented 1 year ago

@mmiron-HC We're still struggling to find a fix for this that won't create bigger problems.

What if I reached out to the disability network and tried to get some staff with cognitive disabilities to help us with a usability test? If, theoretically they tell us it's not a big issue, would that satisfy?

Obviously if they struggle we'll have to keep working on it.

davidgotlieb commented 1 year ago

Issue reported as a Drupal core accessibility issue. Feature should be producing proper code with an nested unordered list so that hierarchy is clear.

Issue reported here: https://www.drupal.org/project/drupal/issues/3327459