WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: using title attribute as form field label

for

From: Kevin Chao
Date: Nov 9, 2011 4:54PM

Having proper iOS virtual on-screen keypad come up is much more
important from an accessibility and usability point, which would be
followed by preventing too many characters from being entered.

Kevin

On 11/9/11, Vincent Young < <EMAIL REMOVED> > wrote:
> Bump. Any opinions on the below:
>
> Using the input type = number on IOS the number keypad comes up but
> maxlength is not honored. For now what is more important, having the
> proper keypad come up or keeping the user from entering too many
> characters? This seems like a real usability/accessibility issue but maybe
> not. If anyone has suggestions about how to get both to work for the date
> example John presented please share.
>
> On Wed, Nov 9, 2011 at 8:41 AM, Steve Faulkner
> < <EMAIL REMOVED> >wrote:
>
>> Hi Jared, have posted a bug against the HTML5 spec about this
>>
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=14740
>>
>> regards
>> steve
>>
>> On 8 November 2011 23:05, Jared Smith < <EMAIL REMOVED> > wrote:
>>
>> > On Tue, Nov 8, 2011 at 2:53 PM, Steve Faulkner wrote:
>> >
>> > > 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.
>> >
>> > I understand. Despite what ARIA says or what accessibility APIs do,
>> > this does not change the definition of the title attribute in the HTML
>> > specification. If we want to redefine title to allow it to be an
>> > alternative for form labeling (or description for frames for that
>> > matter), this should occur in the spec, shouldn't it? You have to have
>> > a very liberal and creative interpretation of the HTML spec to
>> > interpret "advisory information" to mean "accessible name".
>> >
>> > Jared
>> >