WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: [WebAim] differentiate between the edit and read only edit fields.

for

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

From: shankar shan
Date: Fri, Mar 13 2020 2:42AM
Subject: [WebAim] differentiate between the edit and read only edit fields.
No previous message | Next message →

Hello all, greetings.

We are testing the desktop application and the application has the
html document where the document consist multiple sections with the
editable and read only fields.
When the user press the tab key, the visual focus will be on the
section header and keyboard focus will be on the edit Field. Screen
reader announcing as header name and tooltip.
Now, the question is, how should we make screen reader for
differentiate between the edit and read only edit fields.






--
jammed and internet hanged?Reach through the following means:
mobile: +91 7795927572
whats app: +91 7795927572
skype: Shankar.a
email: = EMAIL ADDRESS REMOVED =
Thanks and regards
Shankar
*****

*****

From: glen walker
Date: Fri, Mar 13 2020 3:09PM
Subject: Re: [WebAim] differentiate between the edit and read only edit fields.
← Previous message | Next message →

Regarding editable and readonly fields, you don't have to do anything
special if you have semantic html.

<input>
<input readonly>

These two input fields will be read correctly by screen readers without you
having to do anything extra (assuming you have properly associated labels
for the fields).

I didn't follow what you meant when you said "the visual focus will be on
the section header and keyboard focus will be on the edit Field". How is
the visual focus different from the keyboard focus?

Also, I wouldn't expect my focus to move to a section heading. It's not an
interactive element so shouldn't receive focus.

From: shankar shan
Date: Fri, Mar 13 2020 7:50PM
Subject: Re: [WebAim] differentiate between the edit and read only edit fields.
← Previous message | Next message →

glen, thanks for your prompt reply.
since we are uplifting the screens and, due to restrictions for the
code change, the edit and read only fields does not have the
associated labels.
so, we are making screen reader to read the header's label for the
focused fields.

On 3/14/20, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> Regarding editable and readonly fields, you don't have to do anything
> special if you have semantic html.
>
> <input>
> <input readonly>
>
> These two input fields will be read correctly by screen readers without you
> having to do anything extra (assuming you have properly associated labels
> for the fields).
>
> I didn't follow what you meant when you said "the visual focus will be on
> the section header and keyboard focus will be on the edit Field". How is
> the visual focus different from the keyboard focus?
>
> Also, I wouldn't expect my focus to move to a section heading. It's not an
> interactive element so shouldn't receive focus.
> > > > >


--
jammed and internet hanged?Reach through the following means:
mobile: +91 7795927572
whats app: +91 7795927572
skype: Shankar.a
email: = EMAIL ADDRESS REMOVED =
Thanks and regards
Shankar
*****
ACCESSIBILITY AND USABILITY TESTER AT Cerner Health Care Solutions.
*****

From: Patrick H. Lauke
Date: Sat, Mar 14 2020 2:55AM
Subject: Re: [WebAim] differentiate between the edit and read only edit fields.
← Previous message | Next message →

On 14/03/2020 01:50, shankar shan wrote:
> glen, thanks for your prompt reply.
> since we are uplifting the screens and, due to restrictions for the
> code change, the edit and read only fields does not have the
> associated labels.
> so, we are making screen reader to read the header's label for the
> focused fields.

It would be far less intrusive to add an aria-label or similar to the
inputs, rather than - if I understand the current approach correctly -
making the text acting as a label focusable (as the latter would also
still not give those inputs an actual accessible name, so it will still
be a confusing experience, reliant on users only ever tabbing forward
through the form to get the "label" text, followed by the unlabelled input).

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Murphy, Sean
Date: Sun, Mar 15 2020 4:21PM
Subject: Re: [WebAim] differentiate between the edit and read only edit fields.
← Previous message | No next message

Fully agree with P. The best practise is to fix the issue rather than the aria-label approach as having a visual label will help all users, not only screen reader users.

Sean

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Patrick H. Lauke
Sent: Saturday, 14 March 2020 7:56 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] [WebAim] differentiate between the edit and read only edit fields.

[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.

On 14/03/2020 01:50, shankar shan wrote:
> glen, thanks for your prompt reply.
> since we are uplifting the screens and, due to restrictions for the
> code change, the edit and read only fields does not have the
> associated labels.
> so, we are making screen reader to read the header's label for the
> focused fields.

It would be far less intrusive to add an aria-label or similar to the inputs, rather than - if I understand the current approach correctly - making the text acting as a label focusable (as the latter would also still not give those inputs an actual accessible name, so it will still be a confusing experience, reliant on users only ever tabbing forward through the form to get the "label" text, followed by the unlabelled input).

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke