Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1866043004:
Add a nameFromNode attrib to link output rule (Closed)
|
Created:
4 years, 8 months ago by David Tseng Modified:
4 years, 8 months ago Reviewers:
dmazzoni CC:
chromium-reviews, oshima+watch_chromium.org, aboxhall+watch_chromium.org, nektar+watch_chromium.org, yuzo+watch_chromium.org, je_julie, arv+watch_chromium.org, dtseng+watch_chromium.org, dmazzoni+watch_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionAdd a nameFromNode attrib to link output rule
1. Some sites result in an accessibility tree as follows:
link name=foo children=(heading, paragraph)
We end up reading the link's name when reading the children
(e.g. bar heading 1, foo link
This becomes noisy across multiple instances of this structure across a page.
The nameFromNode attribute only adds the name if it isn't computed based on the contents of the node.
2. Content editables containing spaces come through as non-breaking spaces. In particular, this is seen in Google Docs. Add the literal string for the space so we read it when navigating by character.
TEST=navigate to sites containing links with complex children. Ensure we don't read the link's name.
Navigate by character in Google Docs with braille mode on in chromeVox Next. Ensure we read the space.
Committed: https://crrev.com/d55c1d5f75a2350989549a684db8a4a349d0172b
Cr-Commit-Position: refs/heads/master@{#388599}
Patch Set 1 #Patch Set 2 : #Patch Set 3 : #
Total comments: 1
Patch Set 4 : #Patch Set 5 : Fix tests. #
Messages
Total messages: 22 (10 generated)
Description was changed from ========== Remove name from link enter output rule and include a literal string for non-break spaces. ========== to ========== Remove name from link enter output rule and include a literal string for non-break spaces. 1. Some sites result in an accessibility tree as follows: link name=foo children=(heading, paragraph) We end up reading the link's name when reading the children (e.g. bar heading 1, foo link This becomes noisy across multiple instances of this structure across a page. 2. Content editables containing spaces come through as non-breaking spaces. In particular, this is seen in Google Docs. Add the literal string for the space so we read it when navigating by character. TEST=navigate to sites containing links with complex children. Ensure we don't read the link's name. Navigate by character in Google Docs with braille mode on in chromeVox Next. Ensure we read the space. ==========
dtseng@chromium.org changed reviewers: + dmazzoni@chromium.org
Is the link name dropped? What if the user overrides the name of the link with aria-label? Try this example. In VoiceOver it just reads the aria-label of the link by default and totally ignores what's inside, though you can access it if you interact with it. data:text/html,<button>Before</button><a href="#" aria-label="Override link name"><h2>Heading in link</h2><p>Para in link</p></a><button>After</button> I think we could use nameFrom to figure out whether the name came from the link contents or not
The unfortunate pattern I'm seeing is: <a href="asdf" aria-label"some text here"> <h1 style="max-width=5px">some text here</h1> </a> which results in lots of duplication and lots of lines (per word). Perhaps we should have a separate discussion about how to best handle these cases. Depending on how we arrive on the above block, output is different. On Thu, Apr 7, 2016 at 1:41 PM, <dmazzoni@chromium.org> wrote: > Is the link name dropped? What if the user overrides the name of the link > with > aria-label? > > Try this example. In VoiceOver it just reads the aria-label of the link by > default and totally ignores what's inside, though you can access it if you > interact with it. > > data:text/html,<button>Before</button><a href="#" aria-label="Override > link > name"><h2>Heading in link</h2><p>Para in link</p></a><button>After</ > button> > > I think we could use nameFrom to figure out whether the name came from the > link > contents or not > > > > https://codereview.chromium.org/1866043004/ > > -- > You received this message because you are subscribed to the Google Groups > "Chromium-reviews" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to chromium-reviews+unsubscribe@chromium.org. > -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
I think we should consider the link to be a leaf node in this case. That seems to be what other screen readers do. On Thu, Apr 7, 2016 at 2:09 PM David Tseng <dtseng@chromium.org> wrote: > The unfortunate pattern I'm seeing is: > <a href="asdf" aria-label"some text here"> > <h1 style="max-width=5px">some text here</h1> > </a> > > which results in lots of duplication and lots of lines (per word). > > Perhaps we should have a separate discussion about how to best handle > these cases. Depending on how we arrive on the above block, output is > different. > > On Thu, Apr 7, 2016 at 1:41 PM, <dmazzoni@chromium.org> wrote: > >> Is the link name dropped? What if the user overrides the name of the link >> with >> aria-label? >> >> Try this example. In VoiceOver it just reads the aria-label of the link by >> default and totally ignores what's inside, though you can access it if you >> interact with it. >> >> data:text/html,<button>Before</button><a href="#" aria-label="Override >> link >> name"><h2>Heading in link</h2><p>Para in >> link</p></a><button>After</button> >> >> I think we could use nameFrom to figure out whether the name came from >> the link >> contents or not >> >> >> >> https://codereview.chromium.org/1866043004/ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Chromium-reviews" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to chromium-reviews+unsubscribe@chromium.org. >> > > -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
Unfortunately, that goes against a consistent selection model. I'll file a bug and maybe ew can discuss there. On Thu, Apr 7, 2016 at 3:18 PM, 'Dominic Mazzoni' via Chromium-reviews < chromium-reviews@chromium.org> wrote: > I think we should consider the link to be a leaf node in this case. That > seems to be what other screen readers do. > > On Thu, Apr 7, 2016 at 2:09 PM David Tseng <dtseng@chromium.org> wrote: > >> The unfortunate pattern I'm seeing is: >> <a href="asdf" aria-label"some text here"> >> <h1 style="max-width=5px">some text here</h1> >> </a> >> >> which results in lots of duplication and lots of lines (per word). >> >> Perhaps we should have a separate discussion about how to best handle >> these cases. Depending on how we arrive on the above block, output is >> different. >> >> On Thu, Apr 7, 2016 at 1:41 PM, <dmazzoni@chromium.org> wrote: >> >>> Is the link name dropped? What if the user overrides the name of the >>> link with >>> aria-label? >>> >>> Try this example. In VoiceOver it just reads the aria-label of the link >>> by >>> default and totally ignores what's inside, though you can access it if >>> you >>> interact with it. >>> >>> data:text/html,<button>Before</button><a href="#" aria-label="Override >>> link >>> name"><h2>Heading in link</h2><p>Para in link</p></a><button>After</ >>> button> >>> >>> I think we could use nameFrom to figure out whether the name came from >>> the link >>> contents or not >>> >>> >>> >>> https://codereview.chromium.org/1866043004/ >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Chromium-reviews" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to chromium-reviews+unsubscribe@chromium.org. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Chromium-reviews" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to chromium-reviews+unsubscribe@chromium.org. > -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
PTAL; went ahead and added nameFrom as an attribute for the enter link output rule. On 2016/04/07 22:42:03, David Tseng wrote: > Unfortunately, that goes against a consistent selection model. I'll file a > bug and maybe ew can discuss there. > > On Thu, Apr 7, 2016 at 3:18 PM, 'Dominic Mazzoni' via Chromium-reviews < > mailto:chromium-reviews@chromium.org> wrote: > > > I think we should consider the link to be a leaf node in this case. That > > seems to be what other screen readers do. > > > > On Thu, Apr 7, 2016 at 2:09 PM David Tseng <mailto:dtseng@chromium.org> wrote: > > > >> The unfortunate pattern I'm seeing is: > >> <a href="asdf" aria-label"some text here"> > >> <h1 style="max-width=5px">some text here</h1> > >> </a> > >> > >> which results in lots of duplication and lots of lines (per word). > >> > >> Perhaps we should have a separate discussion about how to best handle > >> these cases. Depending on how we arrive on the above block, output is > >> different. > >> > >> On Thu, Apr 7, 2016 at 1:41 PM, <mailto:dmazzoni@chromium.org> wrote: > >> > >>> Is the link name dropped? What if the user overrides the name of the > >>> link with > >>> aria-label? > >>> > >>> Try this example. In VoiceOver it just reads the aria-label of the link > >>> by > >>> default and totally ignores what's inside, though you can access it if > >>> you > >>> interact with it. > >>> > >>> data:text/html,<button>Before</button><a href="#" aria-label="Override > >>> link > >>> name"><h2>Heading in link</h2><p>Para in link</p></a><button>After</ > >>> button> > >>> > >>> I think we could use nameFrom to figure out whether the name came from > >>> the link > >>> contents or not > >>> > >>> > >>> > >>> https://codereview.chromium.org/1866043004/ > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > >>> Groups "Chromium-reviews" group. > >>> To unsubscribe from this group and stop receiving emails from it, send > >>> an email to mailto:chromium-reviews+unsubscribe@chromium.org. > >>> > >> > >> -- > > You received this message because you are subscribed to the Google Groups > > "Chromium-reviews" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to mailto:chromium-reviews+unsubscribe@chromium.org. > > > > -- > You received this message because you are subscribed to the Google Groups > "Chromium-reviews" group. > To unsubscribe from this group and stop receiving emails from it, send an email > to mailto:chromium-reviews+unsubscribe@chromium.org.
Description was changed from ========== Remove name from link enter output rule and include a literal string for non-break spaces. 1. Some sites result in an accessibility tree as follows: link name=foo children=(heading, paragraph) We end up reading the link's name when reading the children (e.g. bar heading 1, foo link This becomes noisy across multiple instances of this structure across a page. 2. Content editables containing spaces come through as non-breaking spaces. In particular, this is seen in Google Docs. Add the literal string for the space so we read it when navigating by character. TEST=navigate to sites containing links with complex children. Ensure we don't read the link's name. Navigate by character in Google Docs with braille mode on in chromeVox Next. Ensure we read the space. ========== to ========== Add a nameFromNode attrib to link output rule 1. Some sites result in an accessibility tree as follows: link name=foo children=(heading, paragraph) We end up reading the link's name when reading the children (e.g. bar heading 1, foo link This becomes noisy across multiple instances of this structure across a page. The nameFromNode attribute only adds the name if it isn't computed based on the contents of the node. 2. Content editables containing spaces come through as non-breaking spaces. In particular, this is seen in Google Docs. Add the literal string for the space so we read it when navigating by character. TEST=navigate to sites containing links with complex children. Ensure we don't read the link's name. Navigate by character in Google Docs with braille mode on in chromeVox Next. Ensure we read the space. ==========
lgtm Great, I like it https://codereview.chromium.org/1866043004/diff/40001/chrome/browser/resource... File chrome/browser/resources/chromeos/chromevox/common/chrome_extension_externs.js (right): https://codereview.chromium.org/1866043004/diff/40001/chrome/browser/resource... chrome/browser/resources/chromeos/chromevox/common/chrome_extension_externs.js:368: chrome.automation.AutomationNode.prototype.DescriptionFrom; lowercase d in descriptionFrom
The CQ bit was checked by dtseng@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from dmazzoni@chromium.org Link to the patchset: https://codereview.chromium.org/1866043004/#ps60001 (title: " ")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1866043004/60001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1866043004/60001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: linux_chromium_chromeos_ozone_rel_ng on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by dtseng@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from dmazzoni@chromium.org Link to the patchset: https://codereview.chromium.org/1866043004/#ps80001 (title: "Fix tests.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1866043004/80001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1866043004/80001
Message was sent while issue was closed.
Description was changed from ========== Add a nameFromNode attrib to link output rule 1. Some sites result in an accessibility tree as follows: link name=foo children=(heading, paragraph) We end up reading the link's name when reading the children (e.g. bar heading 1, foo link This becomes noisy across multiple instances of this structure across a page. The nameFromNode attribute only adds the name if it isn't computed based on the contents of the node. 2. Content editables containing spaces come through as non-breaking spaces. In particular, this is seen in Google Docs. Add the literal string for the space so we read it when navigating by character. TEST=navigate to sites containing links with complex children. Ensure we don't read the link's name. Navigate by character in Google Docs with braille mode on in chromeVox Next. Ensure we read the space. ========== to ========== Add a nameFromNode attrib to link output rule 1. Some sites result in an accessibility tree as follows: link name=foo children=(heading, paragraph) We end up reading the link's name when reading the children (e.g. bar heading 1, foo link This becomes noisy across multiple instances of this structure across a page. The nameFromNode attribute only adds the name if it isn't computed based on the contents of the node. 2. Content editables containing spaces come through as non-breaking spaces. In particular, this is seen in Google Docs. Add the literal string for the space so we read it when navigating by character. TEST=navigate to sites containing links with complex children. Ensure we don't read the link's name. Navigate by character in Google Docs with braille mode on in chromeVox Next. Ensure we read the space. ==========
Message was sent while issue was closed.
Committed patchset #5 (id:80001)
Message was sent while issue was closed.
Description was changed from ========== Add a nameFromNode attrib to link output rule 1. Some sites result in an accessibility tree as follows: link name=foo children=(heading, paragraph) We end up reading the link's name when reading the children (e.g. bar heading 1, foo link This becomes noisy across multiple instances of this structure across a page. The nameFromNode attribute only adds the name if it isn't computed based on the contents of the node. 2. Content editables containing spaces come through as non-breaking spaces. In particular, this is seen in Google Docs. Add the literal string for the space so we read it when navigating by character. TEST=navigate to sites containing links with complex children. Ensure we don't read the link's name. Navigate by character in Google Docs with braille mode on in chromeVox Next. Ensure we read the space. ========== to ========== Add a nameFromNode attrib to link output rule 1. Some sites result in an accessibility tree as follows: link name=foo children=(heading, paragraph) We end up reading the link's name when reading the children (e.g. bar heading 1, foo link This becomes noisy across multiple instances of this structure across a page. The nameFromNode attribute only adds the name if it isn't computed based on the contents of the node. 2. Content editables containing spaces come through as non-breaking spaces. In particular, this is seen in Google Docs. Add the literal string for the space so we read it when navigating by character. TEST=navigate to sites containing links with complex children. Ensure we don't read the link's name. Navigate by character in Google Docs with braille mode on in chromeVox Next. Ensure we read the space. Committed: https://crrev.com/d55c1d5f75a2350989549a684db8a4a349d0172b Cr-Commit-Position: refs/heads/master@{#388599} ==========
Message was sent while issue was closed.
Patchset 5 (id:??) landed as https://crrev.com/d55c1d5f75a2350989549a684db8a4a349d0172b Cr-Commit-Position: refs/heads/master@{#388599} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
