Thanks for the edit in the Typographical conventions. Could you revise the Radio buttons again? There needs to be an indicator of how the control's exact label will be marked-up in the wiki.
I've been trying some experiments with representations of selected & deselected modes of the checkbox (ballot box). The results have been ... unsatisfactory... so far.
The old representation looks like typeface rendering errors instead of suggesting the GUI control. There isn't any interface that uses a filled box for selected checkbox. And the deselected looks like a placeholder substitution for when the OS font has no renderable glyph for that character. The shadow box was inaccurate in suggested some three dimensionality in the interface... but at least the square's dropshadow didn't look like a browser error.
Unfortunately, the Unicode (ballot box, shadowbox, radio buttons) & SVG images have been failing many cross platform, cross browser tests. The only thing that's been reliable (so far) is a image. (Although the image size relative to the font is still scaling to much because of screen DPIs. On high DPI devices like an iPhone, the image is 1/3 the size of a capital letter.)
The inclusion of the (unfortunately ugly) Label template was intentional. We need some indication that the Exact Text will be found on-screen as labeling for the button (Likewise, with the checkbox. The Template for the checkbox need to evolve. The visual indicator for exact GUI phrasing should be in lock-step with the 'labels' of the GUI dialog section headers.) Embedding the Radio button graphic within the label was another experiment to try to represent the GUI control object as indivisable from its label. Certainly, the selector has less meaning without it's label.
Oddly, the label color highlighting can vary when the 'labeled' content encloses not ASCII objects. It is rendered as full line height (including 'line leading') or just run from baseline to x-height.
I've always found the bold & oddly color-coded 'label' disruptive to learning when reading the wiki. But it DOES tell the reader to look in the GUI for an exact phrase.
The ideal thing would be if we had the ability to call the OS to show the GUI element and label. Then the interface, font styling & backdrop color would match what the user would see in Gramps dialogs on their OS. Despite MediaWiki being originally (& widely) used for software documentation, I've found nothing that supports that kind of capability.
With that capability, the hope is that labels would evolve to leverage the Gramps PO translation files. So the Label template would use the Default Language for web browsing to autoswap in the Translated text string. It's a forlorn hope ... similar to the hope that we'll eventually have the full set of icon files shipped with Gramps. It would be lovely if the wiki was like Gramps -- swapping in the icons for the OS being used by the Browser.