This comment is partially CYA, but lets not forget about T194301: Introduce temporary element on Special:Block UI to invite users to participate in the Partial Block consultation which ran from July 19-23 in multiple languages.

@Wargo suggests changing the UI, too: https://meta.wikimedia.org/wiki/Talk:Community_health_initiative/Partial_blocks#My_proposals

This is still annoying since there is no proper way to hack this.

Hi. I agree with Trizek: Partial Blocks are great, but we dont use them very often, so greyed fields should be hidden as long as 'partial block" is not selected. It will save time when blocking a lot of vandals during RC patrol.

Change 537718 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Hide partial block options when not applicable

https://gerrit.wikimedia.org/r/537718

@Volker_E Are there any accessibility reasons for recommending enable/disable over hide/show?

@Tchanders display: none will hide content from screen reader users as well, but if the show/hide is not sufficently ARIA mapped, it's not being clearly exposed to screen readers what's hidden, what's shown. I assume this was the reason for the comment above and the Partial options always shown disabled.
The other small thing to be cautious about is the whole page moving underneath when the disabled elements would be hidden by default and shown only on Partial.

One small detail for the form, the Sitewide/Partial radio buttons top margin to the parent checkbox seems overly big, it should be reduced, probably by a single page CSS rule for this page to 8px.

Thanks @Volker_E. I've filed your recommendation in T236679: Reduce top-margin for checkboxes on Special:Block. Given your recommendation against hide/show for the partial block options, I am inclined to decline this task.

@Prtksxna Do you have any final ideas for what we can do here?

I am not against hiding the form elements that aren't being used, but, as Volker pointed out, if we do do this we should make sure that the ARIA mappings are correct and we're using aria-expanded and aria-controls correctly. We'll also need to test with screen readers to make sure its working properly. You can read more at — https://www.accessibility-developer-guide.com/examples/sensible-aria-usage/expanded/

In the case that we can't ensure that the hiding/showing is accessible, we should stick with the status quo of full accessibility at the cost of extra scrolling.

Change 537718 abandoned by DannyS712:
Hide partial block options when not applicable

Reason:
Should be done using hide-if

https://gerrit.wikimedia.org/r/537718

Change 570948 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Hide partial block options when not applicable

https://gerrit.wikimedia.org/r/570948

Using HTML form's hide-if should take care of accessibility concerns

In T217363#5699164, @Prtksxna wrote:

In the case that we can't ensure that the hiding/showing is accessible, we should stick with the status quo of full accessibility at the cost of extra scrolling.

The reason is understandable, but may not be accepted by people who use this form multiple times a day. And we still miss a convenient way to locally hack this (like in my common.js).

In T217363#5860532, @DannyS712 wrote:

Using HTML form's hide-if should take care of accessibility concerns

@DannyS712 Thanks for working on this. Can you share screenshots or a screen recording of the end result?

In T217363#6091989, @Niharika wrote:

In T217363#5860532, @DannyS712 wrote:

Using HTML form's hide-if should take care of accessibility concerns

@DannyS712 Thanks for working on this. Can you share screenshots or a screen recording of the end result?

You can see it at http://patchdemo.wmflabs.org/wikis/b02676d0a7043c7e914685e4c1495dd0/w/index.php/Special:Block/Patch_Demo (login with username Patch Demo, password patchdemo1.) - meets the acceptance criteria and works

In T217363#6092030, @DannyS712 wrote:

In T217363#6091989, @Niharika wrote:

In T217363#5860532, @DannyS712 wrote:

Using HTML form's hide-if should take care of accessibility concerns

@DannyS712 Thanks for working on this. Can you share screenshots or a screen recording of the end result?

You can see it at http://patchdemo.wmflabs.org/wikis/b02676d0a7043c7e914685e4c1495dd0/w/index.php/Special:Block/Patch_Demo (login with username Patch Demo, password patchdemo1.) - meets the acceptance criteria and works

Thanks! That looks good to me. @Prtksxna could you take a look at this to make sure your concerns are addressed?

In T217363#6092030, @DannyS712 wrote:

You can see it at http://patchdemo.wmflabs.org/wikis/b02676d0a7043c7e914685e4c1495dd0/w/index.php/Special:Block/Patch_Demo (login with username Patch Demo, password patchdemo1.) - meets the acceptance criteria and works

Thank you! I just tried it and noticed that the partial block menu is open while the page loads and then disappears. I guess this is due to the test wiki it is implemented on?

(I'm adding the User-notice tag, because people will be happy to know when this would be deployed.)

In T217363#6092030, @DannyS712 wrote:

You can see it at http://patchdemo.wmflabs.org/wikis/b02676d0a7043c7e914685e4c1495dd0/w/index.php/Special:Block/Patch_Demo (login with username Patch Demo, password patchdemo1.) - meets the acceptance criteria and works

This looks good 👍🏽

In T217363#5860532, @DannyS712 wrote:

Using HTML form's hide-if should take care of accessibility concerns

@Mooeypoo @Volker_E I don't know much about hide-if. Is it implemented in an accessible way?

In T217363#6103219, @Prtksxna wrote:

In T217363#5860532, @DannyS712 wrote:

Using HTML form's hide-if should take care of accessibility concerns

@Mooeypoo @Volker_E I don't know much about hide-if. Is it implemented in an accessible way?

I actually don't know much about hide-if in HTMLForm, but if it's implemented in HTMLForm, it sounds like it is coming from the backend already hidden, rather than dynamically shown/hidden by the Javascript?

Today I learned ;) https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/htmlform/HTMLForm.php$95

So, it looks like this will make it work properly for JS interactions as-is. I would assume and hope that this is optimized for accessibility, as if it isn't it means that any other form, anywhere else in the stack, is not a11y friendly, which is a deeper issue than this specific code.

My test environment is on the fritz at the moment, so I couldn't test it, but on its face the code looks good. I +1'ed, I need someone to do a run-through test and verify so it can be +2'ed.

I'd definitely not assume anything with HTMLForm, most of it was grown out of one perspective, one specific issue and later one possibly generalized.
Thought we have used hide-if before on a core special page, but a quick search showed only usages in Echo, GrowthExperiments and OAuth. I can't say clearly how accessible it is, everything display: none has to be carefully put on a pillow of ARIA attributes/roles for screen readers to understand normally.

@Volker_E @Prtksxna Can we file a separate task for the follow-up that needs to happen and merge @DannyS712's patch as it stands currently? I think we have delayed on this task way longer than is acceptable.

In T217363#6187443, @Niharika wrote:

@Volker_E @Prtksxna Can we file a separate task for the follow-up that needs to happen and merge @DannyS712's patch as it stands currently? I think we have delayed on this task way longer than is acceptable.

{{ping}}

@Prtksxna Moving this to your column to add requirements for this task.