RE: placeholder text in input controls

Sandi Wassmer wrote:
> 
> The HTML5 placeholder attribute will indeed standardise its use and
> will negate the need for JavaScript to handle placeholder behaviour.

So this is a good thing.


> 
> Irrespective of this, consideration must be given to older/non-modern
> browsers and older screen readers, so bringing it back to the lowest
> common denominator, i.e. raw HTML is the best bet.

Except... the @placeholder attribute *is* raw HTML, at least raw HTML5.
For that matter, so is ARIA (including aria-label) as all of this code is
at the html layer (as opposed to the scripted - JavaScript - layer or the
design - CSS - layer). While developers must always be mindful of the long
tail pattern of AT adoption, and the pace with which older AT is replaced,
we must also remember that there is a social contract between all users
and developers to remain within a reasonable zone of usable software:
nobody here would consider still having to support Netscape 4.7 and/or
JAWS 4, and rightly so.

Specific to @placeholder - it has zero impact on AT/screen readers
regardless of whether the browser being used supports the visual output or
not*, and for older browsers (and honestly, there should be no reason in
2011 that users cannot have a relatively modern, up-to-date browser), at
any rate, for older browsers they will simply ignore both the attribute
and its value. 

(*In a related question(s), _should_ the placeholder value be exposed to
the AAPI? Would this end up being redundant information? Would the user
experience be improved or hindered if it were exposed? I'm not sure at
this time...)


> 
> Ensuring that labels are always in place and appropriately associated
> with form fields will provide a base layer and then titles and
> placeholders can be used as progressive enhancements.

There is no doubt that all form inputs MUST have appropriate labeling for
AT users, however we do have more than one way to apply those labels
today, and it is important that we not get too hung up on being overly
prescriptive on how form inputs are labeled. Modern browsers are supposed
to map the value of <label> and aria-label to the same Accessibility API
value (accName), and AFAIK, they currently all do (if they map to an AAPI
at all - I'm looking at you Opera...)


> 
> As the major screen reader vendors get most of their income from
> government programs supporting VI people in employment, but with 67% of
> VI people of working age in the UK being unemployed, technology
> adoption and particularily mainstream screenreaders are cost
> prohibitive.

1) Browsers: Firefox, Chrome, Safari - cost: $0.00

2) Operating systems: Linux - cost $0.00

3) Screen Reading Programs: NVDA, System Access to Go
(http://www.satogo.com), WebAnywhere
(http://webanywhere.cs.washington.edu/), ChromeVox, Orca, LSR- GNOME
(http://live.gnome.org/LSR), Speakup
(http://www.linux-speakup.org/speakup.html), Emacspeak
(http://emacspeak.sourceforge.net/) - cost: $0.00

4) Looking forward, we also have VoiceOver on iOS and Apple' Mac (Kitty
cat) builds, plus Siri (potential for mobility impaired users = huge) as
well as wok on the Android platform around both speech input and TTS
output: softwares that are being built directly into the emergent
operating systems.


I don't disagree that there is a disparity between those with and without
disabilities, and that this disparity often manifests in disabled users
using older and less capable hardware/software, but the suggestion that
the price of software is holding users back starts to crumble under close
scrutiny. What is really needed is a support network that ensures that
those users who require assistance in keeping their gear/rigs up-to-date
have access to that assistance, whether that's user training, or
hardware/software upgrade clinics.


> As there is no provision for those not in education or
> employment, screen reader hand me downs that rely on older browsers are
> being utilised by many VI people, thus the importance of this approach.

Sandi, are there any hard numbers behind this? Either way, measurable
statistics around this important topic would be highly useful. I honestly
don't think it is as dire as you are painting it out to be, and I feel it
is important that developers be encouraged to 'up their development game',
and that the accessibility community be supportive of that, while at the
same time ensuring that we don't lose the graceful fallback. 

Cheers!

JF

Received on Friday, 9 December 2011 23:25:06 UTC