Remove split button example

[josepharhar]

Split buttons cannot be made accessible:
#1077 (comment)

[scottaohara]

@josepharhar how is that your take away from the other thread?

[josepharhar]

how is that your take away from the other thread?

This is what made me feel like we shouldn't be working on this for now:

I get the motivation behind making a splitbutton, but I think any effort to do so would be better served by being independent of <select> work. Trying to duct tape them together seems like it would degrade the accessibility and usability of both the <select> and the desired splitbutton pattern.

I guess "Split buttons cannot be made accessible" is not the right phrasing, but I'm not sure what else to do here. Do you have any suggestions?

[scottaohara]

my suggestion was what i said before (but elongating that out further now):

Talk about what is expected here from what we could recommend as a markup pattern to guide authors in how to use this to make a custom split button. This is said under the assumption (per our discussions) that there will be no browser re-mapping of the select element's a11y properties, or any additional keyboard functionality added that would match with what native platforms or custom-web implementations of split buttons have attempted to create.

For instance, on the web authors would still have a bit more to do to match these component library examples of split buttons. (can take a look at the markup patterns here to see how they'd differ from the original pattern posted)

• splitButton from Fluent UI
• split button from primeNG, react version - note lack of accName for the down-arrow button part in these examples. tsk tsk...

From discussions with @smhigley, speaking about Fluent specifically, the two-button split button approach linked above is more a result of having to work with what the current web platform allows, than necessarily the preferred approach of emulating split button natively found on windows, which is a single component (single tab stop) with a primary action and a sub-action (more options button). And would need to have considerations built in for touch behavior / target size requirements, so that using a split button can be more usable for those with motor disabilities or using a touch device where precise actions on the smaller part of the button can be difficult. See also the previous version of Fluent UI which more aligned with the 'single button' approach, but had accessibility issues that came from limitations of the web (the referenced split buttons above work around the limitations by diverging from the native-OS expectations for split buttons)

The alternate being, we could also think some more on what else browsers could do by default, if this (re-using the select element instead of creating a specific split button element) is really the path people want to take to create "web native split buttons". This may still not get to 100% what a split button might be desired to be - if native split button feature parity is the end goal. But arguably the browser could at least get closer to the web-versions people have created, per the few i linked to in the above list, and then authors would still have some work to do to make sure they met a11y guidelines, like not creating undersized targets for the split button parts.

Or, we could all just acknowledge the fact that a split button is a separate thing from a select, and it really doesn't matter how many times people try to design things that look like a split button using the customizable select - it's all just fudging around with making select visually look like something it's not, unless you're also willing to do the extra work needed to make the component. And instead, a separate split button proposal would then need to be made.

With all the above, i'm personally fine with any of these approaches. I'm merely trying to make it absolutely clear that if anyone assumed that simply allowing selectedoption to be put inside of a sibling button element was all that was needed to make a split button, then that was a major misunderstanding/miscommunication. It was suggested as an alternative to the hairy situation of having multiple buttons inside of a select element wrapper, and then needing to figure out what the browser would need to do to allow for that / change the mappings for the select and its custom parts.

[gregwhitworth]

Thank you for the PR @josepharhar as always. Two things of feedback:

1. I can't leave a line comment but you kept split buttons in the table of contents and it needs to be removed
2. I agree with the spirit of @scottaohara statement. I personally do think that people will want to produce a split-button variant of a customized select and so we should produce an example that is as accessible as possible. With regards to Scott's recommendation of a new element approach, etc I don't think is a bad idea but I personally would like a stop-gap example in documentation form given I expect people to do this.

That said, I understand if you don't have time to do this now and would prefer to remove the split button from the doc for the time being.

[gregwhitworth]

@josepharhar friendly ping on what your plan will be on this based on the above comment

[josepharhar]

It sounds to me like the selectedoptionelement attribute is too widely scoped of an API to create split buttons and is not expressive enough to tell the browser that they are building a split button and which of the two buttons is supposed to do which thing.

Instead we should create a new button tag or type attribute on the button which allows exactly two buttons to be slotted into the in-page part of the select which forces authors to declare which button is doing which part and therefore allows the browser to apply the correct accessibility mappings to each button and to the select element itself.

Scott does this sound in line with your ideas?

I personally do think that people will want to produce a split-button variant of a customized select and so we should produce an example that is as accessible as possible. With regards to Scott's recommendation of a new element approach, etc I don't think is a bad idea but I personally would like a stop-gap example in documentation form given I expect people to do this.

Yeah, even the selectedoptionelement attribute was intended to be a followup feature. Without a built in feature to do this, does it make sense to provide an example with aria attributes and javascript which does the right thing?

[scottaohara]

@josepharhar yah, i think that does align with what i'd hope for.

in lieu of a specific "split button" element or 'type' for the current button, if we were to keep mentioning it in the explainer we'd need to provide the markup of how we'd "want" someone to create a faux split button using select / selectedoption and a separate button element. It'd also probably make sense to allude to the fact that this is the 'best that can be done' at this point on the web - but that natively "real" split buttons are commonly exposed as a single element.

I just personally don't think we can completely remove the mention of split buttons here, since for better/worse, there was a lot of talk about how this could be used to create those. so either we provide an example per what i just mentioned, or we acknowledge the fact that the split button use case had been discussed - but due to changes in the way this proposal has evolved, that we'd instead recommend it not be used for this use case, and instead look to component libraries like the ones i referenced in my previous comment for how split buttons should be constructed, in lieu of a formal element / button type being created.