WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Possible Incorrect NVDA Behavior

for

Number of posts in this thread: 5 (In chronological order)

From: Jim Homme
Date: Fri, Aug 10 2018 12:34PM
Subject: Possible Incorrect NVDA Behavior
No previous message | Next message →

Hi,
It seems that NVDA may not be honoring that placeholders disappear when you type into edit boxes. Will someone please confirm by looking at this page? https://developer.mozilla.org/en-US/docs/Web/CSS/::placeholder

Thanks.

Jim



==========
Jim Homme
Product Manager
Digital Accessibility
Bender Consulting Services
412-787-8567
https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
People with disabilities, access job openings at https://www.benderconsult.com/careers/job-openings

From: Pratik Patel
Date: Fri, Aug 10 2018 4:28PM
Subject: Re: Possible Incorrect NVDA Behavior
← Previous message | Next message →

As far as I can tell, NVDA reports the text associated with the placeholder.
But there is no actual text in the input field. Let me know if you are
seeing a different behavior.

From: Bim Egan
Date: Sat, Aug 11 2018 2:40AM
Subject: Re: Possible Incorrect NVDA Behavior
← Previous message | Next message →

Hello,

I believe that removal or retention of the visible placeholder text is
controlled by the browser, not the screenreader. Firefox leaves it visible
until the user starts to type, Internet Explorer removes it immediately on
focus.

JavaScript can be used to change these behaviours, but without it the above
is what the user can expect.

HTH,

Bim
-------------
Bim Egan
Personal Email: = EMAIL ADDRESS REMOVED =
Skype ID: bim.accessequals
----------------------------------------
Partner: AccessEquals
W: www.accessequals.com
E: = EMAIL ADDRESS REMOVED =

From: Patrick H. Lauke
Date: Sat, Aug 11 2018 3:17AM
Subject: Re: Possible Incorrect NVDA Behavior
← Previous message | Next message →

I believe the original question here revolves around the fact that NVDA
will announce the placeholder text even when the input has been
filled-in by the user. Visually, that placeholder text isn't shown to
sighted users anymore, but AT may announce it (as the accessible name /
accessible description). This sort of thing is not standardised (there's
no spec that clearly says what AT should/shouldn't do), so it's
essentially how NVDA chooses to deal with placeholder. No right or wrong
about it, but more a question of usefulness. You could argue (depending
on what the placeholder text actually said) that NVDA users get *more*
useful context when revisiting an already filled-out field than users
relying solely on their sight/what the browser shows.

Also worth noting that the behavior in browsers/AT depends on whether or
not the placeholder is the only piece of information that can provide a
name/description to an input.

Take a basic example of a proper <label> and <input>, where the <input>
also has a placeholder


<label for="foo">This is the label</label>
<input id="foo" placeholder="This is the placeholder">

Just testing on Windows at the moment, the following happens:

IE11/JAWS and IE11/NVDA: the input is announced using the label,
placeholder text is not announced at all
Firefox 61/JAWS and Firefox 61/NVDA: the input is announced using the
label, placeholder text is not announced at all
Chrome/JAWS and Chrome/NVDA: the input is announced using the label and
the placeholder text when it's empty; after the user entered some text
in the input, it's only announced using the label and current entered value

Now, it gets more interesting when placeholder is the only text
available to provide an accessible name for the input, e.g. just

<input placeholder="This is the placeholder and there's no label">

In this case:

IE11/JAWS: the input is announced just as "edit"; placeholder text is
not announced
IE11/NVDA: the input is announced using the placeholder text, even when
the user has filled-in the input
Firefox61/JAWS and Firefox 61/NVDA: the input is announced using the
placeholder text, even when the user has filled-in the input (I believe
this is the case queried in the thread starter here by James)
Chrome/JAWS and Chrome/NVDA: the input is announced using the
placeholder text, even when the user has filled-in the input


(so, the only outlier here is IE11/JAWS, all others use placeholder as
the accessible name for the input)

P

On 11/08/2018 09:40, Bim Egan wrote:
> Hello,
>
> I believe that removal or retention of the visible placeholder text is
> controlled by the browser, not the screenreader. Firefox leaves it visible
> until the user starts to type, Internet Explorer removes it immediately on
> focus.
>
> JavaScript can be used to change these behaviours, but without it the above
> is what the user can expect.
>
> HTH,
>
> Bim
> -------------
> Bim Egan
> Personal Email: = EMAIL ADDRESS REMOVED =
> Skype ID: bim.accessequals
> ----------------------------------------
> Partner: AccessEquals
> W: www.accessequals.com
> E: = EMAIL ADDRESS REMOVED =
>

From: Jim Homme
Date: Wed, Aug 15 2018 2:44PM
Subject: Re: Possible Incorrect NVDA Behavior
← Previous message | No next message

Hi,
My contention is that if you are a screen reader user, you should check with a sighted person to see if the placeholder disappears if there is no other label, because this would cause the field to fail the SC about labels and instructions. Also if you are a screen reader user, you may need to make a judgment call about whether you have enough instructions, including the correct way to format fields, so that the field passes Labels and Instructions and Error Prevention. I feel that if screen readers honor the intentions of HTML, that you would get a truly reliable test.

Jim



==========
Jim Homme
Product Manager
Digital Accessibility
Bender Consulting Services
412-787-8567
https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
People with disabilities, access job openings at https://www.benderconsult.com/careers/job-openings