Accessibility: Unordered list not read by voiceover. When targeted by aria-describedby

When the unordered list is target by aria-describedby it is not read by voiceover. So, How can I make it readable by voiceover.

 <div id="body_content">
 <h2 id="heading" aria-describedby="body_content">Heading 1</h2>
 <p>Sample data in the paragraph tag.</p>
 <ul>
 <li>Button 1</li>
 <li>Button 2</li>
 </ul>
 </div>

Scenerio: When the focus is moved to heading tag. The screen reader has to read out heading and after that it should read contents targeted using aria-describedby automatically. While reading, it should also consider and read ul li elements.

If anyone can come up with the solution it would be a great help.

Hi @slugolicious do you have any fix for the requirement??.

Thanks in advance.

edited Nov 12 '18 at 12:03

asked Nov 12 '18 at 9:33

Deepak

52111

Does it changes something if the H2 is outside body_content ? I'm wondering if the fact that aria-describedby targets an enclosing element wouldn't have an influence. Logically I think that you shouldn't do so, because you can't be described by a part of yourself.

– QuentinC
Nov 12 '18 at 12:13

@QuentinC, it is valid to have an element describe itself by having the label point to the parent element. The accessible name calculation accounts for this. See w3.org/TR/accname-1.1/#step2. Look at 2B, second bullet point, "...and the current node is not already part of an aria-describedby traversal...". deepak, note that mentioning an "@name" in the body of your question does not notify that person that they are mentioned in a question. In testing this, NVDA on firefox (63) read the and <ul>. VO on iOS only read the . JAWS on IE didn't read any description.

– slugolicious
Nov 12 '18 at 19:21

Even though this is probably a screen reader bug (not reading all the elements contained in the description), the use of it here is a little weird. What are you trying to accomplish? It's hard to think of a workaround when the real purpose is not known. A heading typically does not need a description, and even if there's an obscure case where it does, why would it need to read paragraphs and lists? A description is supposed to provide further info about an object. A heading is just a beginning of a section and shouldn't need a description too.

– slugolicious
Nov 12 '18 at 19:25

@slugolicious. Actually when the dialog is opened in a android device with the screen reader talkback. Talkback reads the dialog content automatically. But in IOS the focus is moved to the first element and reads it out, but it will not read the whole dialog contents. So, I am trying to include aria-describedby to the focused element, which reads out the referred elements contents, which in turn helps in reading out the contents of the dialog automatically.

– Deepak
Nov 13 '18 at 4:53

but now you a presupposing you know how a native voiceover user interacts with their device. you are trying to force a talkback interaction onto voiceover. that is generally not a good thing to do. as long as your dialog is written semantically correct, then how a screen reader interprets it is up to the screen reader. it won't matter if it's talkback, voiceover, jaws, or nvda. some good articles on accessible modal dialogs are github.com/gdkraus/accessible-modal-dialog and github.com/sweetalert2/sweetalert2

– slugolicious
Nov 14 '18 at 15:55

add a comment |

When the unordered list is target by aria-describedby it is not read by voiceover. So, How can I make it readable by voiceover.

 <div id="body_content">
 <h2 id="heading" aria-describedby="body_content">Heading 1</h2>
 <p>Sample data in the paragraph tag.</p>
 <ul>
 <li>Button 1</li>
 <li>Button 2</li>
 </ul>
 </div>

If anyone can come up with the solution it would be a great help.

Hi @slugolicious do you have any fix for the requirement??.

Thanks in advance.

edited Nov 12 '18 at 12:03

asked Nov 12 '18 at 9:33

Deepak

52111

Does it changes something if the H2 is outside body_content ? I'm wondering if the fact that aria-describedby targets an enclosing element wouldn't have an influence. Logically I think that you shouldn't do so, because you can't be described by a part of yourself.

– QuentinC
Nov 12 '18 at 12:13

@QuentinC, it is valid to have an element describe itself by having the label point to the parent element. The accessible name calculation accounts for this. See w3.org/TR/accname-1.1/#step2. Look at 2B, second bullet point, "...and the current node is not already part of an aria-describedby traversal...". deepak, note that mentioning an "@name" in the body of your question does not notify that person that they are mentioned in a question. In testing this, NVDA on firefox (63) read the and <ul>. VO on iOS only read the . JAWS on IE didn't read any description.

– slugolicious
Nov 12 '18 at 19:21

Even though this is probably a screen reader bug (not reading all the elements contained in the description), the use of it here is a little weird. What are you trying to accomplish? It's hard to think of a workaround when the real purpose is not known. A heading typically does not need a description, and even if there's an obscure case where it does, why would it need to read paragraphs and lists? A description is supposed to provide further info about an object. A heading is just a beginning of a section and shouldn't need a description too.

– slugolicious
Nov 12 '18 at 19:25

@slugolicious. Actually when the dialog is opened in a android device with the screen reader talkback. Talkback reads the dialog content automatically. But in IOS the focus is moved to the first element and reads it out, but it will not read the whole dialog contents. So, I am trying to include aria-describedby to the focused element, which reads out the referred elements contents, which in turn helps in reading out the contents of the dialog automatically.

– Deepak
Nov 13 '18 at 4:53

but now you a presupposing you know how a native voiceover user interacts with their device. you are trying to force a talkback interaction onto voiceover. that is generally not a good thing to do. as long as your dialog is written semantically correct, then how a screen reader interprets it is up to the screen reader. it won't matter if it's talkback, voiceover, jaws, or nvda. some good articles on accessible modal dialogs are github.com/gdkraus/accessible-modal-dialog and github.com/sweetalert2/sweetalert2

– slugolicious
Nov 14 '18 at 15:55

add a comment |

When the unordered list is target by aria-describedby it is not read by voiceover. So, How can I make it readable by voiceover.

 <div id="body_content">
 <h2 id="heading" aria-describedby="body_content">Heading 1</h2>
 <p>Sample data in the paragraph tag.</p>
 <ul>
 <li>Button 1</li>
 <li>Button 2</li>
 </ul>
 </div>

If anyone can come up with the solution it would be a great help.

Hi @slugolicious do you have any fix for the requirement??.

Thanks in advance.

edited Nov 12 '18 at 12:03

asked Nov 12 '18 at 9:33

Deepak

52111

When the unordered list is target by aria-describedby it is not read by voiceover. So, How can I make it readable by voiceover.

 <div id="body_content">
 <h2 id="heading" aria-describedby="body_content">Heading 1</h2>
 <p>Sample data in the paragraph tag.</p>
 <ul>
 <li>Button 1</li>
 <li>Button 2</li>
 </ul>
 </div>

If anyone can come up with the solution it would be a great help.

Hi @slugolicious do you have any fix for the requirement??.

Thanks in advance.

ios html5 accessibility voiceover uiaccessibility

edited Nov 12 '18 at 12:03

asked Nov 12 '18 at 9:33

Deepak

52111

edited Nov 12 '18 at 12:03

asked Nov 12 '18 at 9:33

Deepak

52111

edited Nov 12 '18 at 12:03

asked Nov 12 '18 at 9:33

Deepak

52111

asked Nov 12 '18 at 9:33

Deepak

52111

asked Nov 12 '18 at 9:33

Deepak

52111

Does it changes something if the H2 is outside body_content ? I'm wondering if the fact that aria-describedby targets an enclosing element wouldn't have an influence. Logically I think that you shouldn't do so, because you can't be described by a part of yourself.

– QuentinC
Nov 12 '18 at 12:13

@QuentinC, it is valid to have an element describe itself by having the label point to the parent element. The accessible name calculation accounts for this. See w3.org/TR/accname-1.1/#step2. Look at 2B, second bullet point, "...and the current node is not already part of an aria-describedby traversal...". deepak, note that mentioning an "@name" in the body of your question does not notify that person that they are mentioned in a question. In testing this, NVDA on firefox (63) read the and <ul>. VO on iOS only read the . JAWS on IE didn't read any description.

– slugolicious
Nov 12 '18 at 19:21

Even though this is probably a screen reader bug (not reading all the elements contained in the description), the use of it here is a little weird. What are you trying to accomplish? It's hard to think of a workaround when the real purpose is not known. A heading typically does not need a description, and even if there's an obscure case where it does, why would it need to read paragraphs and lists? A description is supposed to provide further info about an object. A heading is just a beginning of a section and shouldn't need a description too.

– slugolicious
Nov 12 '18 at 19:25

@slugolicious. Actually when the dialog is opened in a android device with the screen reader talkback. Talkback reads the dialog content automatically. But in IOS the focus is moved to the first element and reads it out, but it will not read the whole dialog contents. So, I am trying to include aria-describedby to the focused element, which reads out the referred elements contents, which in turn helps in reading out the contents of the dialog automatically.

– Deepak
Nov 13 '18 at 4:53

but now you a presupposing you know how a native voiceover user interacts with their device. you are trying to force a talkback interaction onto voiceover. that is generally not a good thing to do. as long as your dialog is written semantically correct, then how a screen reader interprets it is up to the screen reader. it won't matter if it's talkback, voiceover, jaws, or nvda. some good articles on accessible modal dialogs are github.com/gdkraus/accessible-modal-dialog and github.com/sweetalert2/sweetalert2

– slugolicious
Nov 14 '18 at 15:55

add a comment |

Does it changes something if the H2 is outside body_content ? I'm wondering if the fact that aria-describedby targets an enclosing element wouldn't have an influence. Logically I think that you shouldn't do so, because you can't be described by a part of yourself.

– QuentinC
Nov 12 '18 at 12:13

@QuentinC, it is valid to have an element describe itself by having the label point to the parent element. The accessible name calculation accounts for this. See w3.org/TR/accname-1.1/#step2. Look at 2B, second bullet point, "...and the current node is not already part of an aria-describedby traversal...". deepak, note that mentioning an "@name" in the body of your question does not notify that person that they are mentioned in a question. In testing this, NVDA on firefox (63) read the and <ul>. VO on iOS only read the . JAWS on IE didn't read any description.

– slugolicious
Nov 12 '18 at 19:21

Even though this is probably a screen reader bug (not reading all the elements contained in the description), the use of it here is a little weird. What are you trying to accomplish? It's hard to think of a workaround when the real purpose is not known. A heading typically does not need a description, and even if there's an obscure case where it does, why would it need to read paragraphs and lists? A description is supposed to provide further info about an object. A heading is just a beginning of a section and shouldn't need a description too.

– slugolicious
Nov 12 '18 at 19:25

@slugolicious. Actually when the dialog is opened in a android device with the screen reader talkback. Talkback reads the dialog content automatically. But in IOS the focus is moved to the first element and reads it out, but it will not read the whole dialog contents. So, I am trying to include aria-describedby to the focused element, which reads out the referred elements contents, which in turn helps in reading out the contents of the dialog automatically.

– Deepak
Nov 13 '18 at 4:53

but now you a presupposing you know how a native voiceover user interacts with their device. you are trying to force a talkback interaction onto voiceover. that is generally not a good thing to do. as long as your dialog is written semantically correct, then how a screen reader interprets it is up to the screen reader. it won't matter if it's talkback, voiceover, jaws, or nvda. some good articles on accessible modal dialogs are github.com/gdkraus/accessible-modal-dialog and github.com/sweetalert2/sweetalert2

– slugolicious
Nov 14 '18 at 15:55

Does it changes something if the H2 is outside body_content ? I'm wondering if the fact that aria-describedby targets an enclosing element wouldn't have an influence. Logically I think that you shouldn't do so, because you can't be described by a part of yourself.

– QuentinC
Nov 12 '18 at 12:13

@QuentinC, it is valid to have an element describe itself by having the label point to the parent element. The accessible name calculation accounts for this. See w3.org/TR/accname-1.1/#step2. Look at 2B, second bullet point, "...and the current node is not already part of an aria-describedby traversal...". deepak, note that mentioning an "@name" in the body of your question does not notify that person that they are mentioned in a question. In testing this, NVDA on firefox (63) read the and <ul>. VO on iOS only read the . JAWS on IE didn't read any description.

– slugolicious
Nov 12 '18 at 19:21

Even though this is probably a screen reader bug (not reading all the elements contained in the description), the use of it here is a little weird. What are you trying to accomplish? It's hard to think of a workaround when the real purpose is not known. A heading typically does not need a description, and even if there's an obscure case where it does, why would it need to read paragraphs and lists? A description is supposed to provide further info about an object. A heading is just a beginning of a section and shouldn't need a description too.

– slugolicious
Nov 12 '18 at 19:25

@slugolicious. Actually when the dialog is opened in a android device with the screen reader talkback. Talkback reads the dialog content automatically. But in IOS the focus is moved to the first element and reads it out, but it will not read the whole dialog contents. So, I am trying to include aria-describedby to the focused element, which reads out the referred elements contents, which in turn helps in reading out the contents of the dialog automatically.

– Deepak
Nov 13 '18 at 4:53

but now you a presupposing you know how a native voiceover user interacts with their device. you are trying to force a talkback interaction onto voiceover. that is generally not a good thing to do. as long as your dialog is written semantically correct, then how a screen reader interprets it is up to the screen reader. it won't matter if it's talkback, voiceover, jaws, or nvda. some good articles on accessible modal dialogs are github.com/gdkraus/accessible-modal-dialog and github.com/sweetalert2/sweetalert2

– slugolicious
Nov 14 '18 at 15:55

add a comment |

0

active

oldest

votes

Your Answer

StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53259289%2faccessibility-unordered-list-not-read-by-voiceover-when-targeted-by-aria-descr%23new-answer', 'question_page');

);

Post as a guest

Name

Required, but never shown

0

active

oldest

votes

0

active

oldest

votes

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Dfyjkt