Re: placeholder text in input controls

Hi all,

A note from the low-vision side: unless properly re-styled, placeholder text is almost invisible for a user with poor contrast perception.

Even with a good contrast, identifying an edit box with a text that dissapears when the box receives focus can be a big issue for magnifier users. Add to this some fancy almost-invisible grey-over-white borders (absurdly excluded from WCAG) and you will end up with a form that is invisible for users with low vision. Of course this can also happen with off-screen labels, but at least the user can disable styles and see them (not probable, but the possibility exists).

Sandi: same situation in Spain. Technical Assistants do not provide support for any setup out of windows+IE+JAWS.

I also guess that in developing countries -with slow connections or outdated hardware- obtaining and running newer versions of browsers / AT is not a trivial issue. Moreover, I'd bet that the process itself of finding and downloading these tools cannot always be performed in an accessible way.

Cheers,
Ramón.

Sandi loves debate, too:

> Oh John - you do love a good debate, so.....
> 
> UK VI User Statistics:
> 48% Windows XP
> 23% IE6
> 67% of VI people of working age are unemployed
> 
> With welfare to work reforms over the past 40 years having no impact on the percentage of VI people of working age in the UK in employment, "cost" of entry is about so many more factors than the quality or price of any assistive technology. 
> 
> Access to mainstream hardware, software and ICT training is very limited and even if these were readily available, mobility as well as social confidence are major factors. In addition to this, the knowledge and skills amomgst those providing support to VI people is focussed on the major AT vendors, and there is no formal tuition available for any of the free or low cost screen readers, even for those in education or employment. 
> 
> I have been lobbying Government to embrace NVDA, VoiceOver, which I use, and Orca, for starters, as well as other great free and low cost AT in their employment programs. I am also lobbying for Government to provide access to AT & training for those not in employment or education, and for this to be means tested for those not seeking employment and as part of the wider welfare to work programs for those who are.
> 
> As it stands  the barriers to accessing great tech like NVDA are way too high for most, so although nascent technologies like HTML5 and WAI-ARIA are the way forward, I cannot advocat leaving people who are digitally disadvantaged behind when providing well supported HTML attributes, such as labels associated with form fields, provide tbe building blocks for anyone to access.
> 
> Best,
> 
> Sandi
> 
> Sent from my iPad
> 
> Sandi Wassmer
> Copious Ltd / digital agency
> t: 020 8446 3806
> m: 07808 887 201
> e: sandi@copious.co.uk
> w: www.copious.co.uk 
> 
> Read Sandi's Action for Blind People Blog:
> www.actionforblindpeople.org.uk/your-community/blogs/sandi-wassmer/
> 
> Follow Sandi on Twitter:
> www.twitter.com/SandiWassmer
> 
> Follow Copious on Twitter:
> www.twitter.com/copious
> 
> Company Registration number: 4213718      
> VAT Registration Number 774 4416 14
> 
> If you receive this e-mail in error please notify the sender by replying using the words Misdirected E-mail in the subject, and then delete the message and any attachments from your system.
> 
> 
> On 9 Dec 2011, at 23:24, "John Foliot" <jfoliot@stanford.edu> wrote:
> 
>> 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 Saturday, 10 December 2011 02:08:50 UTC