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.