[#22890] - Adds keyup trigger on showon elements
- Closed
- 31 Oct 2018
- Medium
- Build: staging
- # 22890
- Diff
- regularlabs:patch-2
User tests: Successful: Unsuccessful:
Summary of Changes
This PR will make elements show/hide when typing in a text field.
Currently, the showon elements are only updated when the value of a field changes (onChange).
However, when typing in a text field, the change event is only triggered when the focus is moved to another element.
So the PR changes that behaviour to also update the showon fields when the keyup event is triggered.
Testing Instructions
Add this code to a form xml file (inside a fieldset).
We'll use the banners config file for this example:
administrator/components/com_banners/config.xml
<field name="my_text_field" type="text" label="My Text Field" />
<field name="my_note" type="note" class="alert alert-success"
description="Shows when the text field is not empty"
showon="my_text_field!:"
/>
Before PR
Start typing in the text field. Nothing happens.
But when clicking outside the textfield, or hitting tab, the note shows.
After PR
Start typing in the empty text field.
The note shows as soon as it is not empty.
The note also hides again as soon as you delete the characters in the text field.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | JavaScript |
Why not? Can you explain?
sorry on my phone so was brief
it is not good because it adds a visual distraction while perfoming a task
Well, the distraction is what you would want.
The same can be said for all fields using the showon.
When you change a select option, other fields can appear.
Not sure there is such a difference between changing a select, clicking a radio button or entering text. The are all: changing field values.
Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide.html
the difference is that the current behaviour occurs as a distinct action performed on completion of another action
the proposed behaviour occurs at the same time as the user is trying to input data
Ok, let me approach it from this side:
You have extra fields/settings/notices/whatever showing when a text field is not empty (or has a certain value).
Currently:
The user inputs something. Those fields do not show.
The user clicks on the save & close button.
The user has never had a chance to see those extra fields.
They are not my accessibility rules. We really should try to adhere to them so that Joomla is for everyone
I am not sure your interpretation of said rule applies to this though.
Going by that interpretation it would put the breaks on any dynamic (elastic) search fields too.
For instance, the current input fields for tags (ie in articles) show different results whilst typing.
Same difference.
never said the current code is accessible - something we are trying to fix - i just dont want to introduce new non accessible code
"unless the auto-updating is part of an activity where it is essential."
hardly essential ;)
any way I have nothing further to say
as for your comment on elastic search functionality not being accessible there are many options we can use such as https://alphagov.github.io/accessible-autocomplete/examples/
Nothing more to say: that stops a conversation in its tracks.
So: all those examples are accessible.
And all those examples show dynamic changing content whilst typing.
Anyway, I guess your word rules, so this is a dead end.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-10-31 16:49:50 |
| Closed_By | ⇒ | regularlabs | |
| Labels |
Added:
?
|
||
I'm with @regularlabs on this. I fail to see the difference between the changes here and https://alphagov.github.io/accessible-autocomplete/examples/
@ciar4n there are a lot of differences if you enable a screensaver
@regularlabs I am only expressing an opinion and offering advice as to its accessibility. Feel.free.to take it to the a11y team for them to make a decision.
@brianteeman As you did respond I'll add my last response to this PR too.
I think this PR got side-tracked by a discussion about a11y that I think misses the point.
Also the stuff you say as a response seems to be inconsistent to me. So I'll try to start from the beginning as far as I interpret this case.
Firstly, I'll state that this PR does NOT affect any use of the showon in Joomla core. As Joomla doesn't show/hide fields based on values of text fields anywhere.
So this ONLY affects extensions that implement the showon based on text field values.
And I bet that in all those cases it is desired to show those fields as soon as the text field contains the defined text.
To continue, you stated in the beginning that the a11y issue here is one of 'distraction'.
This is not an issue of screen readers (you mentioned screensavers in your reply, but I assume you mean screen readers). As there is - as far as I can tell - no difference for screen readers in:
- Focus on text field. Enter text. Hit tab. Other fields appear.
- Focus on text field. Enter text. Other fields appear. Hit tab.
So the issue is - again, as far as I understand - the part about 'distraction'.
So extra content (fields, notices, whatever) showing/hiding when typing.
But I think this is no different than the current implementation of the showon functionality.
Currently the showon fields will show/hide when the value of a certain field changes.
But with text fields it does NOT show/hide when the value changes. It only show/hides when the value changes AND the focus is left from the field (or enter is hit).
Say we have a notice that shows when a radio field is set to 'Yes'.
This notice will show/hide on the change event of that radio field.
So using the keyboard:
- You focus on the radio field
- You use the arrow keys to change the selected radio option.
- The notice shows, but focus is still on the radio button.
On the other hand, with text fields:
- You focus on the radio field
- You enter text.
- The notice DOES NOT shows, and focus is still on the text field.
So this is inconsistent behaviour.
Anyway, I won't go back and forth any more on this, as this little fix has cost me more than enough of my precious [enter swear word] time already.
I only see this resulting in one of two scenarios.
So I ask you to respond one of these 2 answers.
-
Yes, indeed, there is no (additional) accessibility issue here. All's good.
Result: I'll create a new clean PR of this and we'll just forget about this whole useless discussion. -
No, you are wrong. This is still an issue and a show stopper.
Result: I'll forget about this whole thing. And just add javascript to my extensions to add the keyup functionality to the fields I use this on. Thereby (once again) working around the issues Joomla throws, instead of fixing them.
Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
There is a clarification on what in that document on what is considered "auto-updating" and "distraction". This PR does not seem to fall into the case of auto-updating on a preset time, nor it is unrelated to the user actions, it is the result of the user actions
The intent of this Success Criterion is to avoid distracting users during their interaction with a Web page.
"Moving, blinking and scrolling" refers to content in which the visible content conveys a sense of motion. Common examples include motion pictures, synchronized media presentations, animations, real-time games, and scrolling stock tickers.
"Auto-updating" refers to content that updates or disappears based on a preset time interval.
Common time-based content includes audio, automatically updated weather information, news, stock price updates, and auto-advancing presentations and messages. The requirements for moving, blinking and scrolling content and for auto-updating content are the same except that:
Thanks. That pretty much squashes the argument.
I'll make a new clean PR shortly.
This is not great for accessibility