It seems to me that if the client insists on having one of the options pretend to be a label, then they’d better be totally okay with a user not making a selection at all. value=“0” should be a valid option and if that’s an error, let the back end deal with it. Semantically, you probably agree this is not good use (a choice as a name of the choices who then actually isn’t meant to really be a choice).
I think we web developers want to be really careful with aria-hidden. There’s been a large debate about it, which included debates on whether browsers should be able to detect screen readers or other AT and then whether web developers should have access to that information, and then whether that’s a privacy invasion etc.
The various screen reader makers as well as the browsers have also had long discussions about what to do when there is aria-hidden. In general the concensus seems to be that it should reflect a true state of something on the web page: that it is indeed intended to be hidden, from all users. http://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/
So one example of possible good use of aria-hidden is when you’ve made a modal popup and the “rest of the page” part should basically not exist for the user, any user, until the user has either done something within the popup, or closed it. Like when a Javascript alert appears: your only options are within that alert, or closing the alert. But usually sighted people can still actually see the rest of the page. Nowadays a trendy half-opaque dark area is layered over the page, to make the modal stand out, but imagine the modal’s HTML is also outside the whole page element. Some people have taken to using aria-hidden=“true” on the rest of the page part (this only works if the modal is NOT a child of the page), meaning “dearest all users: this page element does not exist. You cannot see it, or interact with it. There is only XUL— er, there is only the modal.”
This should be an acceptable use of aria-hidden because often the rest of the page is unintentionally “visible” (available) to screen reader users, and in a modal situation, there should only be the modal. Aria-hidden is a special way to tell AT (and browsers) “this element is meant to be hidden from all users.”
AT writers and browser vendors also have to deal with, what if the author (you) put aria-hidden on something and inside are focusable children (or on focusable thingies? like options?)? Some browsers and AT will scour the entire tree at every change of events to check if now someone has an aria-hidden state, and then if so if any focusabled are descendents, blah blah. They may ignore aria-hidden on something that is otherwise normally within the default tab order, figuring you’ve made a mistake as an author.
For these reasons I’m really careful with aria-hidden. Anything you have hidden anyway, like display: none stuff, input type=“hidden”, etc, could reasonably have aria-hidden added as an extra hint to state to AT.
When trying to reduce verbosity, it starts getting a bit more muddled as to whether this is a good thing: should we have AT users seeing a different version of the page than sighted ones? Now since basically you have two versions of a label (a real label and an option being used as a label), you could argue that you are actually still showing one version of things to all users. But I think there can be a better way. Unless you’re always going to manually move the focus to the first “real” option whenever a user focusses on the select? You shouldn’t be able to focus on something that’s hidden.
Especially if the back end will be configured to reject the first option as a valid one, you could try using it as a label for both the sighted and the AT users.
<option value="0" id="fake_label">Choose your favorite city</option>```
It is legal to let children label parents. aria-labelledby will override any outside labels, so you could keep that other label for older browsers/AT, but newer ones would ignore the real label. You still have the weirdness that this is actually an option. That is its default role and it has option behaviours built-in the browser and all that.
Another option is to do some fancy CSS and Javascript where the label is visible and covering the select, until users have both focussed on the select *and* made a change so something other than the first item is selected. The first item, if truly allowed as an option, would really say "no preference".
```<div class=”favcity-wrapper”> <-- position: relative
<label for="favcity">Choose your favorite city</label><-- position: absolute, Javascript listens
<select id="favcity" name="select">
<option value="0" aria-label="no preference"> </option>```
This does sound like a lot of work that might be silly though, but we've seen it done on regular text inputs, where the label is mimicking a placeholder. At least the above, while being more convoluted, lets us keep sanity with the semantics of the HTML. The option can now act like what it is, an option. The label can be a label. AT and non-AT users are honestly seeing, and interacting with, the same thing.
It's more honest, in my opinion, but it's also more work, esp. styling form controls cross-browser can be a b*tch. But otherwise I'd still rather let the controls be a bit more verbose than try aria-hidden on a focusable thingie.
You might already have extra verbosity if there's a legend, which sometimes annoyingly gets announced before every control inside the fieldset. Or the user might have ZoomText, which in IE for some reason not only reads out all titles, but with radio buttons and checkboxes, the values of the controls are read out. So often these users get to hear a lot of nonsense along with the labels (and you can't help this, it's some kind of ZT bug and it doesn't happen in Firefox).