Active On, Status No

phiw13 · 2023-05-02 01:02:11

Bloke wrote #335391:

Fixed, with luck. Thank you.

Hmm. Not really. Maybe I explained it wrongly. I take the Edit plugin page as an example.

Issue 1: the radio/checkbox set where you had:

<div class="txp-form-field-label">
    <label for="flags">flags</label>
 </div>

in this case, the whole <label for=flags> is not needed, as the <label> associated with (and naming) the radio is specified further down. See the various radio sets on the Preferences panel for a working example. You currently have <label>flags</label>, the reasoning remains the same.

This only applies to radio and checkbox sets.

Issue 2: the link (association) between the input and its label. Example: the edit help textarea where you originally had:

<div class="txp-form-field edit-help-raw">
  <div class="txp-form-field-label">
    <label for="help_raw">Help</label>
  </div>
  <div class="txp-form-field-value">
    <textarea name="help_raw" class="help code" cols="96" rows="32" dir="ltr" spellcheck="false">Something</textarea>
  </div>
</div>

Note the lack of id on the textarea. The link between the label and the textarea is non-existent as far as AT is concerned (and the validator would issue you a warning).

What you need here is an ID – id="help_raw" .

But what you have now (commit linked above) is

<div class="txp-form-field edit-help-raw">
  <div class="txp-form-field-label">
    <label>Help</label>
  </div>
  <div class="txp-form-field-value">
    <textarea name="help_raw" class="help code" cols="96" rows="32" dir="ltr"></textarea>
  </div>
</div>

This is actually valid html :-( but the link is again non-existent). You can do a simple test, click on the label for the “Edit help” textarea to focus the textarea, nothing happens. Or in Firefox, right click on the textarea and choose “Inspect Accessibility Properties”. You will see a flag telling you of the need to “name” the form field. (screenshot)

The same applies to all <label> / <input type=text /> pairs (and <select /> or <textarea />). Currently only the Edit plugin panel is affected I think.

I have uploaded the current generated html for that Edit plugin panel here (without any css/js/img). I have added the necessary ids to my plugin edit mockup

Bloke · 2023-05-02 07:24:36

Ah okay, thanks for bearing with me. In which case the InputLabel class is acting up. I thought I mirrored what it does in the procedural case but maybe it’s not working. I’ll compare it to the existing function and see if I can figure out what I’m doing wrong. Might be because I’m calling Label twice or something.

In fact, that’s probably it. The Checkbox itself calls for a Label, and then InputLabel adds another wrapper around it. Hmmm. Might have to manually fudge that or rethink how the content is injected into the InputLabel combo.

Bloke · 2023-05-02 07:55:58

Actually, maybe not. I’m a little confused now. Looking at the prefs panel as a blueprint, some of the labels have a <label> (the ones with a single input element, for example, such as Theme directory, and Default panel) but others such as anything with a combination input control (e.g. Enable development theme preview?) don’t. They just have raw text inside the txp-form-field-label div, so if you click on those labels, they don’t jump to the input control(s).

Is there any rhyme or reason behind this? Is it because control can only be passed to a single input when a label is clicked? So if there’s more than one input (a pair of radios, a set of checkboxes, …) then there’d be no sane way to choose which one, or it would make the life of those with assistive tech difficult?

I’m unsure why some are treated differently and if it makes sense to change this so all labels are treated equal somehow.

Bloke · 2023-05-02 08:14:39

Actually, even the prefs panel isn’t immune. Some new fields such as the Enhanced email YesNoRadioSet has a bogus <label for="enhanced_email"> because it’s calling the UI library under the hood and that assumes that everything must have a label.

I suspect we’ll need to build exceptions into the InputLabel class somehow so the label can be optional if the control itself has labels already.

Bloke · 2023-05-02 08:32:37

Sorry for spamming the thread. Intriguingly, when we build prefs there are some exceptions. Namely, anything that is tagged with yesnoradio as an html input type, and the is_dst field. What we should have done is also added enhanced_email as an exception here. Maybe others. Although the enhanced_email field is a yes-no-radio control, it has additional logic attached so it’s treated differently and uses a custom HTML type to trigger this.

The inputLabel() function manages this by being told which fields are exception conditions, and forcing the label blank in those cases. That then renders a bare gTxt() string instead of a label.

The UI InputLabel class indeed does mirror this behaviour: if the label passed in is blank, it will dutifully render a bare gTxt() string. Unfortunately, when the InputLabel is instantiated, I tried to be too clever and if the label parameter is blank, it assumes the name instead and assigns that as the label. This means the label field is effectively never empty so the bare gTxt() portion of the code is never traversed. So everything gets a label. Bad, Stef. Bad.

What I need to do instead is flag internally that the label is blank and check this later on at the render stage. An easyish fix. Then the inputLabel() function and InputLabel class should output comparable HTML.

The only snag then, when we move to fully integrating the UI library into the prefs panel, is to work out a way of specifying which fields are to get the label and which aren’t. Probably the best way is to do it inside the InputLabel class itself: if we can somehow inspect the wrapped input control, if it’s of type YesNoRadio, CheckboxSet, or RadioSet (or others??) then override any label that might have been set and render raw gTxt() strings instead. That’s more elegant, and less error prone when new UI elements/prefs are introduced, than relying on the coder knowing they have to add the control to an exception list to opt out of label tag generation.

Will have to see what I can do. Thanks for your continued patience (and diligence at keeping this in check!) as this is ironed out.

Last edited by Bloke (2023-05-02 08:33:27)

phiw13 · 2023-05-02 08:49:16

Is there any rhyme or reason behind this? Is it because control can only be passed to a single input when a label is clicked? So if there’s more than one input (a pair of radios, a set of checkboxes, …) then there’d be no sane way to choose which one, or it would make the life of those with assistive tech difficult?

Yes there is. a set of radio buttons, or a set of checkboxes (that is more that one control in a field) have a <label /> for each individual control – each radio button has one to name it. How else would you distinguish between the two(or more) radios ?

<p>choose a colour: </p>
<p> <input type=radio name=colour id=colour-red> <label for=colour-red>sunrise  orange</label>
<input type=radio name=colour id=colour-green> <label for=colour-green>deep ocean green</label><p>

…while text fields (<input type=text />) only have one control in field.

If your newly added prefs for Mail don’t follow that pattern they need fixing (i think the server summer / winter time thingie preference has a similar pattern).

–^–

PS in the markup above, the name attribute is the descriptor of for the payload that is send to the database/server/mailprocessor/… whereas the id attribute is what establishes the relation with the <label> ( aka IDREF). name and id need not be identical, of course.

–^–

edit

While I was typing the above, I see that you’ve added some more post that makes my post partly un-needed.

Last edited by phiw13 (2023-05-02 08:52:14)

Bloke · 2023-05-02 15:08:23

phiw13 wrote #335397:

How else would you distinguish between the two(or more) radios ?

Yeah, I get that. Sorry I wasn’t clear. I meant is there a design pattern that could put focus on the checkbox/radio group when the label was clicked, e.g. I dunno:

<div class="txp-form-field-label">
    <label for="flags">flags</label>
</div>
<div class="txp-form-field-value" id="flags">
    <label for="flags-1"><input class="checkbox" id="flags-1" name="flags[]" type="checkbox" value="1">&#160;plugin_has_prefs</label>
    <label for="flags-2"><input class="checkbox" id="flags-2" name="flags[]" type="checkbox" value="2">&#160;plugin_lifecycle_notify</label>
</div>

So when you click on the main label, it selects the div surrounding all the controls? Or can clicked labels only shift focus to individual input elements?

If your newly added prefs for Mail don’t follow that pattern they need fixing (i think the server summer / winter time thingie preference has a similar pattern).

Yes, the is_dst item is special. The enhanced_mail is another. There may be more that use custom html handlers, which should have been added to the exception list.

If I can figure out how to handle the exceptions more elegantly than listing them, I’ll do it.

Bloke · 2023-05-02 18:11:02

Okay, slightly more involved than I expected, but hopefully a more robust and flexible approach. It now no longer assumes that the input name is the reference that the for attribute uses. By default, it will be if you don’t tell it otherwise, but I’ve extended the $label syntax so you can specify the label and an optional ID to use as the target id attribute reference. I’ve sprinkled that liberally throughout the plugins panel’s Edit step, and it seems to be holding up.

Next test is to see what happens if I use it on the Prefs panel and to see if I can get it to automatically flip between ‘label+for’ and ‘no label’ based on the type of content that it is targeting.

So, more changes to come but please check the Plugins panel to see if it holds up to scrutiny now. Thank you.

phiw13 · 2023-05-03 00:14:22

Bloke wrote #335398:

Yeah, I get that. Sorry I wasn’t clear. I meant is there a design pattern that could put focus on the checkbox/radio group when the label was clicked, e.g. I dunno:

<div class="txp-form-field-label">...

So when you click on the main label, it selects the div surrounding all the controls? Or can clicked labels only shift focus to individual input elements?

div by default is not a focusable element so you would need some help… JS…

I’ll try to have a look at your recent update/commit. But Golden Week holidays.

phiw13 · 2023-05-03 12:27:19

So, more changes to come but please check the Plugins panel to see if it holds up to scrutiny now.

I had a brief look earlier today on the demo server with a minimal plugin. So far, the panel holds well, the link between label and the respective controls are correct. getting there!

Textpattern CMS

Textpattern CMS support forum

#49 2023-05-02 01:02:11

Re: Active On, Status No

Bloke wrote #335391:

#50 2023-05-02 07:24:36

Re: Active On, Status No

#51 2023-05-02 07:55:58

Re: Active On, Status No

#52 2023-05-02 08:14:39

Re: Active On, Status No

#53 2023-05-02 08:32:37

Re: Active On, Status No

#54 2023-05-02 08:49:16

Re: Active On, Status No

#55 2023-05-02 15:08:23

Re: Active On, Status No

phiw13 wrote #335397:

#56 2023-05-02 18:11:02

Re: Active On, Status No

#57 2023-05-03 00:14:22

Re: Active On, Status No

Bloke wrote #335398:

#58 2023-05-03 12:27:19

Re: Active On, Status No

Board footer