Buttons prop `children` mandatory about source

[SiAdcock]

the docs need more clarity regarding this.

I've added an Accessibility section near the top of the Button documentation. Let me know if you think this will be helpful or if it could be improved.

[liywjl]

Thanks for adding this 👍 I think this is a good step, if I have any better ideas I will share

[SiAdcock]

Hi @liywjl, can you give me an example of where this would be useful? Note, if you want only an icon to be visible, you can pass the hideLabel prop

[liywjl]

Here is an example of a work around we had to do in a recent update because children was a mandatory prop: https://github.com/guardian/discussion-rendering/pull/345/files#diff-b5928ae26d810ad0f00591179422632ce95a546bf892f9a776ace078f7b19d4dR296-R308

[liywjl]

we had to add an empty object as child to satisfy the prop requirement:

<Button icon={XXX} hideLabel={true}>{}</Button>

ideally we wouldn't need to add the empty object:

<Button icon={XXX} hideLabel={true}/>

[SiAdcock]

Thanks @liywjl. The reason we make the children mandatory is to ensure something is announced by screen readers. Can you think of some text that will help a screen reader user understand the purpose of the button? Apologies if you have implemented an alternative way of doing this.

[liywjl]

I see that makes a lot more sense! I think however this behaviour isn't quite obvious, I noticed others leaving the object blank as well during upgrade. I am unsure what might be the best way of communicating this to other developers? Maybe add some documentation? Maybe use a separate prop for description?

[SiAdcock]

Yes, it sounds like a tricky one. I agree the docs need more clarity regarding this.

a separate prop for description

Can you flesh out that proposal a little? Do you mean an optional prop that would be announced by screen readers when children are not passed? At this point, we need to make the (unsafe and untrue) assumption that everybody is testing their work with a screen reader, and that they question how to ensure that a button with no text label is still announced by a screen reader.

I noticed others leaving the object blank as well during upgrade

That's not good 😞 My expectation was that if the API caused friction like this, people would question why that friction exists and try to address it. Perhaps they checked the docs and the docs weren't obvious, so they assumed it was a bug, found a workaround and moved on? It's good that you raised the question here, so I really appreciate your engagement with this issue 🙂