web: placeholder not anymore reported correctly by screen readers

[JulienCochuyt]

Impacted versions: 11

Steps to reproduce: Browse to any form with a many2one reference field with placeholder, such as the parent field on a partner.

Current behavior: Screen readers do not report placeholder correctly, as it is interspersed with \ufeff as of #30439.

Expected behavior: Placeholder should be suitably reported.

Tested with screen readers JAWS 18.0 and NVDA 2018.4

[Yenthe666]

@nle-odoo possible side effect of your commit https://github.com/odoo/odoo/pull/30439/files - can you check?

[nle-odoo]

Hello,

The fix has already been changed 9 days ago so it is only applied to google chrome: https://github.com/odoo/odoo/commit/8183f92de4d

this is currently only in 10.0 but should be forward-ported up to master in the following days.

Without the hack, the fields are broken in any case, we are hoping that google chrome will respond/fix to one of the issue (eg. this one is the one where our issue is most accurately described: https://crbug.com/928305) or that we find another hack that do not cause this issue.

If this is still an issue for google chrome user, I am not sure what you mean by "Screen readers do not report placeholder correctly", my expectation was that either the screen reader would ignore invisible zero width characters (and read "City"), or at worst would read "c i t y". Is it the case or is there something even worse?

And second question, for user of google chrome with a screen reader, do you know any determining factors that we could know from the browser to indicate "user is using a screen reader" so in this instance we do not do the hack? (in this instance we would still have two list with the erroneous browser one over the one from odoo)

[JulienCochuyt]

this is currently only in 10.0 but should be forward-ported up to master in the following days.

I guess/hope it should be forward-ported to 11.0 as well, that is, everywhere the original commit has been merged.

Without the hack, the fields are broken in any case, we are hoping that google chrome will respond/fix to one of the issue (eg. this one is the one where our issue is most accurately described: https://crbug.com/928305) or that we find another hack that do not cause this issue.

The root fault is not on Google Chrome here. (At least on 11.0) M2O fields are not rendered as proper WAI combo-boxes. We have altered our 11.0 to render them correctly, and Google Chrome does not mess with the drop-down menu anymore, while still providing autocomplete for regular text fields.

If this is still an issue for google chrome user, I am not sure what you mean by "Screen readers do not report placeholder correctly", my expectation was that either the screen reader would ignore invisible zero width characters (and read "City"), or at worst would read "c i t y". Is it the case or is there something even worse?

In Braille, it is most often rendered as "c i t y", not right, but not a show-stopper. The speech output depends on the speech synthesizer used. eSpeak with NVDA says "c, i, t, y": much more disturbing spoken than in Braille. Eloquence with JAWS or NVDA says "c, question mark, i, question mark, t, question mark, y, question mark" : This is really difficult to work with, and Eloquence is a pretty popular speech synthesizer.

And second question, for user of google chrome with a screen reader, do you know any determining factors that we could know from the browser to indicate "user is using a screen reader" so in this instance we do not do the hack? (in this instance we would still have two list with the erroneous browser one over the one from odoo)

There might be JS hacks, but nothing reliable. I've read that for a Windows-centric approach, one can detect the use of MSAA with Flash but, please, don't. Accessibility matters not only for visually impaired people. The same APIs and behaviors might be exhibited by screen readers, content highlighters, voice control apps, … Trying to detect and adapt to all possible cases is most likely a dead-end. Hence, the need for WAI.

[nle-odoo]

I guess/hope it should be forward-ported to 11.0 as well, that is, everywhere the original commit has been merged.

Yes, the last forward-port was 13 days ago (https://github.com/odoo/odoo/commits/11.0) and usually it is once a week. if it was not forward-ported on the next forward-port like it should be, I would just commit it myself.

The root fault is not on Google Chrome here. (At least on 11.0) M2O fields are not rendered as proper WAI combo-boxes. We have altered our 11.0 to render them correctly, and Google Chrome does not mess with the drop-down menu anymore, while still providing autocomplete for regular text fields.

Interesting, but I could not reproduce testing several things.

For example here I have a street and country I do not want autocomplete on: https://jsfiddle.net/yqfjxn3w/

I still have autocomplete on either: country screenshot and street screenshot

The behavior to me seems forced in any case if there is at least 3 addresses regexes from google chrome autofill_regex_constants.cc that matches the fields, and the only way to not have it is doing something like autocomplete="random-string-azrzarzaarz" which from some reports do not work in some other browser or our current ugly placeholder hack.

And this is a particular behavior that only happen since google chrome 71.

Do you have an idea of how this could be modified with WAI combo-boxes to not have autocomplete and keeping the placeholders intact: https://jsfiddle.net/v3bq859x/ ?

Note that in a bugfix in stable, some fixes can be done because the probability that they breaks existing instance or custom code is too high.

In Braille, it is most often rendered as "c i t y", not right, but not a show-stopper. The speech output depends on the speech synthesizer used. eSpeak with NVDA says "c, i, t, y": much more disturbing spoken than in Braille. Eloquence with JAWS or NVDA says "c, question mark, i, question mark, t, question mark, y, question mark" : This is really difficult to work with, and Eloquence is a pretty popular speech synthesizer.

Okay, sorry for the bother, but do you know if there is other character that may be better suited. U+FEFF was chosen because we have had previous issue that in some window/font configuration that similar invisible character caused an error.

I have made a file with character that could fill the same purpose: https://jsfiddle.net/5hbcrszp/

Thanks for the complete response.

[pedrobaeza]

This seems unanswered after last response from Odoo, so closing. Let me know if not.