WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: using title attribute as form field label

for

From: Vincent Young
Date: Nov 9, 2011 2:54AM


Cool. Question for you or anyone else with interest: using the input type
= number on IOS the number keypad comes up which makes things convenient.
However, currently the number type does not respect the maxlength
attribute. Maxlength is nice on IOS because when you have reached the
maxlength and tap on a character, nothing is voiced, signaling you've
reached the max. From a usability standpoint what do you find more...
usable. The prevention of typing in too many characters or the number
keypad appearing?

On Tue, Nov 8, 2011 at 11:12 PM, Kevin Chao < <EMAIL REMOVED> > wrote:

> Vincent,
> Excellent job! Thanks! Works great on iPhone, iOS 5, Safari, and
> VoiceOver. It's great when swiping left/right to go to previous/next
> element, using web rotor>form field (SWIPING UP/DOWN for previous/next form
> field) and Apple wireless keyboard to TAB and SHIFT-TAB among form fields.
>
> Label is read before edit box. When focused on form field, birthday,
> label, and edit box is spoken. VoiceOver properly sees the three edit boxes
> as being in an unordered list.
>
> Sent from my iPhone
>
> On Nov 9, 2011, at 1:02 AM, Vincent Young < <EMAIL REMOVED> > wrote:
>
> > Kevin I would typically design my form so the label appears before the
> form
> > field visually and in HTML. John's example has the label appearing after
> > the form field (if I remember correctly) so I stuck to the design.
> Edited
> > and put the labels first, but after taking a second look, reworked it.
> The
> > date parts are in an unordered list and the forward slash is inserted
> with
> > the "content" CSS style declaration (could've also done a background
> > image). I think this example is my favorite.
> >
> > http://webhipster.com/testing/accessibility/birthday/index.html
> >
> > Mmmmm... clean.
> >
> >
> >
> >
> >
> > On Tue, Nov 8, 2011 at 9:03 PM, Kevin Chao < <EMAIL REMOVED> >
> wrote:
> >
> >> Hi Vincent,
> >>
> >> This is working great with Firefox 10 Nightly and NVDA 2012.1 Snapshot
> in
> >> that:
> >> navigating through form fields with TAB, E, or F; NVDA is reading
> >> "Birthday, (MM, DD, or YYYY), edit has auto complete"
> >>
> >> However, from the top, using DOWN ARROW to navigate through the form:
> >> Birthday
> >> Edit has Autocomplete
> >> MM
> >>
> >> The label "MM" should come before "edit has autocomplete"
> >>
> >> Kevin
> >>
> >> On 11/8/11, Vincent Young < <EMAIL REMOVED> > wrote:
> >>> John your implementation is pretty sexy. Lots of different ways to go
> >>> about this. I had some fun with it and came up with my own
> >> implementation:
> >>>
> >>> http://webhipster.com/testing/accessibility/birthday/index.html
> >>>
> >>> <form role="form" action="">
> >>> <div>
> >>> <label id="birthday" for="month">Birthday</label>
> >>> </div>
> >>> <div>
> >>> <input id="month" type="number" name="day" size="2"
> >>> aria-labelledby="birthday mm" />
> >>> <label id="mm" for="month"><abbr title="Two Digit
> >>> Month">MM</abbr></label>
> >>> </div>
> >>> <div>&nbsp;/&nbsp;</div>
> >>> <div>
> >>> <input id="day" type="number" name="day" size="2"
> >>> aria-labelledby="birthday dd" />
> >>> <label id="dd" for="day"><abbr title="Two Digit
> >>> Day">DD</abbr></label>
> >>> </div>
> >>> <div>&nbsp;/&nbsp;</div>
> >>> <div>
> >>> <input id="year" type="number" name="year" size="4"
> >>> aria-labelledby="birthday yyyy" />
> >>> <label id="yyyy" for="year"><abbr title="Four Digit
> >>> Year">YYYY</abbr></label>
> >>> </div>
> >>> </form>
> >>>
> >>> If any interest, happy to discuss.
> >>>
> >>> On Tue, Nov 8, 2011 at 1:53 PM, Steve Faulkner
> >>> < <EMAIL REMOVED> >wrote:
> >>>
> >>>> Hi Jared,
> >>>>
> >>>> you wrote:
> >>>>
> >>>>> There's nothing in HTML or accessibility specifications that tell AT
> >>>>> to use the title attribute as a label replacement.
> >>>>
> >>>> Besides what James has pointed out (ARIA implementation guide), it
> >> should
> >>>> be noted that there is no specification that tells user agents how
> many
> >>>> HTML features should be mapped and/or interpreted by the accessibility
> >>>> layer, thats what the HTML to Platform Accessibility APIs
> Implementation
> >>>> Guide
> >>>> http://dev.w3.org/html5/html-api-map/overview.html is starting to
> >>>> document.
> >>>> Note in the section titled accessible name and description
> calculation (
> >>>> http://dev.w3.org/html5/html-api-map/overview.html#calc) the title
> >>>> attribute is included in accessible name calculation. The main reason
> >> for
> >>>> this is that every browser maps the title attribute to the accessible
> >> name
> >>>> property in every accessibility API and have done so for many versions
> >> ( i
> >>>> would suggest for as long as they have had accessibility support).
> >>>>
> >>>> For AT that use information exposed via an accessibility API, it is
> the
> >>>> accessible name property they use regardless of whether the source of
> >> the
> >>>> name is from the label element, aria attribute, element content or
> title
> >>>> attribute.
> >>>>
> >>>> regards
> >>>> Stevef
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 8 November 2011 15:56, Jared Smith < <EMAIL REMOVED> > wrote:
> >>>>
> >>>>> I have several concerns over the use of the title attribute value for
> >>>>> labeling controls:
> >>>>>
> >>>>> - It shouldn't be used if a visible text label is present on the
> page.
> >>>>> <label> should be used instead - it works in old browsers, and also
> >>>>> provides enhanced mouse accessibility, primarily for users with motor
> >>>>> disabilities.
> >>>>>
> >>>>> - As defined in the HTML spec, title attribute is for "advisory
> >>>>> information". If a form field is inaccessible without the title
> >>>>> attribute value, this sure sounds like more than "advisory
> >>>>> information".
> >>>>>
> >>>>> - There's nothing in HTML or accessibility specifications that tell
> AT
> >>>>> to use the title attribute as a label replacement. They just happen
> to
> >>>>> do this on their own. This behavior is really no different than IE
> >>>>> showing alt text in tooltips which everyone railed against as being a
> >>>>> violation of the spec. It makes me uncomfortable relying on the
> >>>>> non-standard quirks of screen readers for accessibility. As has been
> >>>>> noted, different screen readers treat the presentation of title
> >>>>> differently - and understandably so because a standard behavior is
> not
> >>>>> documented anywhere because the attribute is not even intended to
> work
> >>>>> this way.
> >>>>>
> >>>>>
> >>>>> With all of this said, it works relatively well. It just makes me
> >>>>> squirm a little bit. I tend to use off-screen <label> to ensure
> >>>>> accessibility in these situations.
> >>>>>
> >>>>> Jared
> >>>>>