![]() |
Template:Screen reader-only is permanently
protected from editing because it is a
heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by
consensus, editors may use {{
edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's
documentation to add usage notes or
categories.
Any contributor may edit the template's sandbox. This template does not have a testcases subpage. You can create the testcases subpage here. |
This is the
talk page for discussing improvements to the
Screen reader-only template. |
|
Some questions for the page watchers (maybe just Rexx). :^)
.visualhide
. I'm trying to get rid of it and made
Template:Accessible hidden briefly for that reason, but clearly not needed. :^)-- Izno ( talk) 16:50, 2 December 2020 (UTC)
complex and requires a certain degree of browser compliance. Effectively it places the text inside a 1px square and tells the browser not to display any content inside and outside of it. A screen reader ignores those display directives and will still read the text as normal.I experimented and concluded that we don't support
clip-path
, so I actually did implement Cloud4's code (almost) directly. If you check the history of
Template:Sronly/styles.css, you'll see that the "large negative text-indent" was
added some two months later, and not by me. I don't consider it adds anything, other than confusing the browser about where the leftmost piece of text is..visualhide
, then I've forgotten about it. I'm 68 years old and my memory gets worse every passing day, so I have to rely on youngsters to spot these things for me. Nevertheless, if I were aware of it, I wouldn't have used it for two reasons: (1) the code there allows the 1 pixel square to display a dot, and if you move it well offscreen to the left, you'll sometimes end up with a horizontal scroll bar – maybe not on a Wikipedia page, but I've had that happen to me on clients' websites, so I dislike the "large negative text-indent" hack through force of habit; (2) If I'm using a template, I almost always prefer to apply styles at the TemplateStyles level, even if they duplicate classes in Common.css, because they are then insulated from changes in Common.css and can be fine-tuned for the particular application. You also don't have to go searching for where the class is defined (if it's defined at all).alt
text. On point 3, I agree that using elements outside the viewpoint is a bad idea, as it does tend to generate scrollbars and cause other problems. It's much better to keep stuff within the graphical viewpoint but visually suppressed. —
SMcCandlish
☏
¢ 😼 03:45, 15 December 2020 (UTC)@ RexxS: Can this template technically also be used for things other than text, like an entire table? If that's possible, is it also possible to make a template that tells screen readers to exclude content? For example, if a table tailor-made to be used by screen readers is placed in a {{sronly}} template above a table made for people who do not use a screen reader, could the latter be ignored by screen readers if it was in a {{srexclude}} template or something? I'm just wondering as this might be helpful as a compromise in situations where rowspan is perhaps helpful to those who do not use screen readers, but is obviously a detriment to those who do. Other style considerations/consensus would apply regardless of whether a screen reader table and a non-screen reader table are both present; this is not about avoiding that, but for a typical discography table, for example, which uses rowspan heavily in multiple columns, do you think it might be helpful if there was a version made specifically for screen readers above the standard table? Like is it possible to use {{sronly}} for things more complicated than text alone? Heartfox ( talk) 06:04, 10 December 2020 (UTC)
@
Heartfox: The template can be used with any content that can be properly placed inside a template, I think. It simply tells the browser to display it content in a 1px by 1px window (and then clips display even of that pixel). Using wiki-markup like tables can be problematical, because of the pipe character, so that we're better off putting an html table inside {{
sronly}}. The template wraps its content inside a <span>...</span>
, so any wiki-text that generates a new paragraph (blank lines, for example) will close that span, and it's necessary to keep line feeds to a minimum. The MediaWiki software will eventually produce a new paragraph when a table is present and so the browser will see the following text in a new paragraph.
For example:
{{sronly |1=
<table class="wikitable">
<caption>Example</caption>
<tr>
<th>One</th>
<th>Two</th>
</tr><tr>
<td>three</td>
<td>four</td>
</tr></table>Note here [[#next section|Skip the second table]]
gives:
One | Two |
---|---|
three | four |
which is not rendered by the browser, but is there in the html, so a screen reader can read it as normal.
Hiding text from a screen-reader is a different question altogether, and I don't know of a way of doing that within the MediaWikia software. Of course, you could work around it by having the first table inside {{ sronly}} and immediately after the end of the table have a note saying something like "The table above is optimised for screen readers and only visible to them. It is duplicated below in non-optimised form. Skip the second table. The link in the note would be to an anchor inserted just after the second table. There may be other solutions or work-arounds. -- RexxS ( talk) 14:28, 10 December 2020 (UTC)
I agree with Izno above "against any approach of duplicating tables for any reason". However, I did also come here wondering whether this template or a split-off were capable of doing a "nosr" version, that is: "everyone but screen readers". A bit like how there is <noscript>
to provide alternative content. One potential use of this is in the case of {{
abbr}}
. I'm informed that many screen-reader users do not get the title=
content that provides the expansion of the abbreviation (either because their SR software cannot handle it, or because it's an optional feature they have not turned on and maybe do not even know about). We could use sronly to present an alternative, in <span>
form, that gave this content as actual text (e.g.: "UN [abbrev. for 'United Nations']", and then use a "nosr" feature to suppress the original <abbr>
code and its mouse-over tooltip stuff, so no screen-reader users get the content twice. —
SMcCandlish
☏
¢ 😼 03:38, 15 December 2020 (UTC)
W3C's validator is throwing errors when I test a page that uses this template [1]:
Error: Element
style
not allowed as child of elementp
in this context. (Suppressing further errors from this subtree.)From line 72, column 133; to line 72, column 187
...est</span><style data-mw-deduplicate="TemplateStyles:r993651011">.mw-pa...
Contexts in which element
style
may be used:
Where metadata content is expected.
In anoscript
element that is a child of ahead
element.
Content model for elementp
:
Phrasing content.
And:
Error: A
link
element must not appear as a descendant of abody
element unless thelink
element has anitemprop
attribute or has arel
attribute whose value containsdns-prefetch
,modulepreload
,pingback
,preconnect
,prefetch
,preload
,prerender
, orstylesheet
.From line 81, column 209; to line 81, column 291
.../a></span><link rel="mw-deduplicated-inline-style" href="mw-data:TemplateStyles:r993651011"/><span...
The second would seem fixable by giving it an itemprop
value, or adding a value to rel
, if that wouldn't break anything. Dunno about the first. And maybe these are both just general issues with templates that use TemplateStyles.
—
SMcCandlish
☏
¢ 😼 04:07, 15 December 2020 (UTC)
<style>...</style>
to define its classes, every use of any template that makes use of TemplateStyles will include a style tag at the place in the body of the page where the template is used. If you want text to comply with the specification that only allows style tags inside head elements, you will have to forbid the use of TemplateStyles completely. Good luck with that. --
RexxS (
talk) 16:41, 15 December 2020 (UTC)![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Could not find the Phabricator task, but clip-path
property can now be saved in TemplateStyles, see
Шаблон:ЗКА:Быстрые/styles.css page in Russian Wikipedia for a quick example.
Template:Screen reader-only/styles.css can be updated to reflect that.
stjn 10:29, 30 April 2023 (UTC)
[[Visible{{sronly|spoken}}]]
causes:
[[Visiblespoken]]
[[Visible{{sronly|spoken}}After]]
causes:
[[VisiblespokenAfter]]
[[<abbr title="hover text">Visible{{sronly|spoken}}</abbr>]]
causes:
[[ Visiblespoken]]
And placing [[link|<abbr title="hover text">Visible</abbr>{{sronly|spoken}}]]
at the very top of a page will sometimes result in the spoken text being printed inline.
I noticed these when trying to use this to improve accessibility on template:tooltip, Rjjiii ( talk) 18:08, 11 July 2023 (UTC)
Hi. Is it possible to add a third parameter to the template for text to be read only when a screen reader is not used? InfiniteNexus ( talk) 04:04, 23 October 2023 (UTC)
{{
screen reader-only|Megan|M3GAN}}
.
InfiniteNexus (
talk) 04:51, 23 October 2023 (UTC)
M3GAN (pronounced "Megan") ...doesn't appear to be broken for anyone. — SMcCandlish ☏ ¢ 😼 05:00, 23 October 2023 (UTC)
The "3" in M3GAN refers to the fact that the robot is the third-generation model.(made-up example). InfiniteNexus ( talk) 05:52, 23 October 2023 (UTC)
{{
Screen reader-only|spelled c-o-v-f-e-f-e}}
. Which makes me think of another use for it in a different article where a terminological difference is being drawn between jargon terms sett and set, which I now realize will probably be pronounced identically by screen readers. But none of this calls for a new parameter. Maybe there is some kind of use for the proposed parameter, but these examples aren't it. A danger with such a parameter is that editors are apt to think it needs to be filled in, and would put unwise things in it on a regular basis. —
SMcCandlish
☏
¢ 😼 07:01, 23 October 2023 (UTC)
This template will occasionally fail to hide the text. It's not just within links, but I'm not sure what all scenarios cause it. It looks like in some situations the template styles are never given to the browser. I put the CSS inline in the sandbox, and the issues seem to go away.
This packs the presentation into the content though, Rjjiii ( talk) 23:08, 26 December 2023 (UTC)
![]() |
Template:Screen reader-only is permanently
protected from editing because it is a
heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by
consensus, editors may use {{
edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's
documentation to add usage notes or
categories.
Any contributor may edit the template's sandbox. This template does not have a testcases subpage. You can create the testcases subpage here. |
This is the
talk page for discussing improvements to the
Screen reader-only template. |
|
Some questions for the page watchers (maybe just Rexx). :^)
.visualhide
. I'm trying to get rid of it and made
Template:Accessible hidden briefly for that reason, but clearly not needed. :^)-- Izno ( talk) 16:50, 2 December 2020 (UTC)
complex and requires a certain degree of browser compliance. Effectively it places the text inside a 1px square and tells the browser not to display any content inside and outside of it. A screen reader ignores those display directives and will still read the text as normal.I experimented and concluded that we don't support
clip-path
, so I actually did implement Cloud4's code (almost) directly. If you check the history of
Template:Sronly/styles.css, you'll see that the "large negative text-indent" was
added some two months later, and not by me. I don't consider it adds anything, other than confusing the browser about where the leftmost piece of text is..visualhide
, then I've forgotten about it. I'm 68 years old and my memory gets worse every passing day, so I have to rely on youngsters to spot these things for me. Nevertheless, if I were aware of it, I wouldn't have used it for two reasons: (1) the code there allows the 1 pixel square to display a dot, and if you move it well offscreen to the left, you'll sometimes end up with a horizontal scroll bar – maybe not on a Wikipedia page, but I've had that happen to me on clients' websites, so I dislike the "large negative text-indent" hack through force of habit; (2) If I'm using a template, I almost always prefer to apply styles at the TemplateStyles level, even if they duplicate classes in Common.css, because they are then insulated from changes in Common.css and can be fine-tuned for the particular application. You also don't have to go searching for where the class is defined (if it's defined at all).alt
text. On point 3, I agree that using elements outside the viewpoint is a bad idea, as it does tend to generate scrollbars and cause other problems. It's much better to keep stuff within the graphical viewpoint but visually suppressed. —
SMcCandlish
☏
¢ 😼 03:45, 15 December 2020 (UTC)@ RexxS: Can this template technically also be used for things other than text, like an entire table? If that's possible, is it also possible to make a template that tells screen readers to exclude content? For example, if a table tailor-made to be used by screen readers is placed in a {{sronly}} template above a table made for people who do not use a screen reader, could the latter be ignored by screen readers if it was in a {{srexclude}} template or something? I'm just wondering as this might be helpful as a compromise in situations where rowspan is perhaps helpful to those who do not use screen readers, but is obviously a detriment to those who do. Other style considerations/consensus would apply regardless of whether a screen reader table and a non-screen reader table are both present; this is not about avoiding that, but for a typical discography table, for example, which uses rowspan heavily in multiple columns, do you think it might be helpful if there was a version made specifically for screen readers above the standard table? Like is it possible to use {{sronly}} for things more complicated than text alone? Heartfox ( talk) 06:04, 10 December 2020 (UTC)
@
Heartfox: The template can be used with any content that can be properly placed inside a template, I think. It simply tells the browser to display it content in a 1px by 1px window (and then clips display even of that pixel). Using wiki-markup like tables can be problematical, because of the pipe character, so that we're better off putting an html table inside {{
sronly}}. The template wraps its content inside a <span>...</span>
, so any wiki-text that generates a new paragraph (blank lines, for example) will close that span, and it's necessary to keep line feeds to a minimum. The MediaWiki software will eventually produce a new paragraph when a table is present and so the browser will see the following text in a new paragraph.
For example:
{{sronly |1=
<table class="wikitable">
<caption>Example</caption>
<tr>
<th>One</th>
<th>Two</th>
</tr><tr>
<td>three</td>
<td>four</td>
</tr></table>Note here [[#next section|Skip the second table]]
gives:
One | Two |
---|---|
three | four |
which is not rendered by the browser, but is there in the html, so a screen reader can read it as normal.
Hiding text from a screen-reader is a different question altogether, and I don't know of a way of doing that within the MediaWikia software. Of course, you could work around it by having the first table inside {{ sronly}} and immediately after the end of the table have a note saying something like "The table above is optimised for screen readers and only visible to them. It is duplicated below in non-optimised form. Skip the second table. The link in the note would be to an anchor inserted just after the second table. There may be other solutions or work-arounds. -- RexxS ( talk) 14:28, 10 December 2020 (UTC)
I agree with Izno above "against any approach of duplicating tables for any reason". However, I did also come here wondering whether this template or a split-off were capable of doing a "nosr" version, that is: "everyone but screen readers". A bit like how there is <noscript>
to provide alternative content. One potential use of this is in the case of {{
abbr}}
. I'm informed that many screen-reader users do not get the title=
content that provides the expansion of the abbreviation (either because their SR software cannot handle it, or because it's an optional feature they have not turned on and maybe do not even know about). We could use sronly to present an alternative, in <span>
form, that gave this content as actual text (e.g.: "UN [abbrev. for 'United Nations']", and then use a "nosr" feature to suppress the original <abbr>
code and its mouse-over tooltip stuff, so no screen-reader users get the content twice. —
SMcCandlish
☏
¢ 😼 03:38, 15 December 2020 (UTC)
W3C's validator is throwing errors when I test a page that uses this template [1]:
Error: Element
style
not allowed as child of elementp
in this context. (Suppressing further errors from this subtree.)From line 72, column 133; to line 72, column 187
...est</span><style data-mw-deduplicate="TemplateStyles:r993651011">.mw-pa...
Contexts in which element
style
may be used:
Where metadata content is expected.
In anoscript
element that is a child of ahead
element.
Content model for elementp
:
Phrasing content.
And:
Error: A
link
element must not appear as a descendant of abody
element unless thelink
element has anitemprop
attribute or has arel
attribute whose value containsdns-prefetch
,modulepreload
,pingback
,preconnect
,prefetch
,preload
,prerender
, orstylesheet
.From line 81, column 209; to line 81, column 291
.../a></span><link rel="mw-deduplicated-inline-style" href="mw-data:TemplateStyles:r993651011"/><span...
The second would seem fixable by giving it an itemprop
value, or adding a value to rel
, if that wouldn't break anything. Dunno about the first. And maybe these are both just general issues with templates that use TemplateStyles.
—
SMcCandlish
☏
¢ 😼 04:07, 15 December 2020 (UTC)
<style>...</style>
to define its classes, every use of any template that makes use of TemplateStyles will include a style tag at the place in the body of the page where the template is used. If you want text to comply with the specification that only allows style tags inside head elements, you will have to forbid the use of TemplateStyles completely. Good luck with that. --
RexxS (
talk) 16:41, 15 December 2020 (UTC)![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Could not find the Phabricator task, but clip-path
property can now be saved in TemplateStyles, see
Шаблон:ЗКА:Быстрые/styles.css page in Russian Wikipedia for a quick example.
Template:Screen reader-only/styles.css can be updated to reflect that.
stjn 10:29, 30 April 2023 (UTC)
[[Visible{{sronly|spoken}}]]
causes:
[[Visiblespoken]]
[[Visible{{sronly|spoken}}After]]
causes:
[[VisiblespokenAfter]]
[[<abbr title="hover text">Visible{{sronly|spoken}}</abbr>]]
causes:
[[ Visiblespoken]]
And placing [[link|<abbr title="hover text">Visible</abbr>{{sronly|spoken}}]]
at the very top of a page will sometimes result in the spoken text being printed inline.
I noticed these when trying to use this to improve accessibility on template:tooltip, Rjjiii ( talk) 18:08, 11 July 2023 (UTC)
Hi. Is it possible to add a third parameter to the template for text to be read only when a screen reader is not used? InfiniteNexus ( talk) 04:04, 23 October 2023 (UTC)
{{
screen reader-only|Megan|M3GAN}}
.
InfiniteNexus (
talk) 04:51, 23 October 2023 (UTC)
M3GAN (pronounced "Megan") ...doesn't appear to be broken for anyone. — SMcCandlish ☏ ¢ 😼 05:00, 23 October 2023 (UTC)
The "3" in M3GAN refers to the fact that the robot is the third-generation model.(made-up example). InfiniteNexus ( talk) 05:52, 23 October 2023 (UTC)
{{
Screen reader-only|spelled c-o-v-f-e-f-e}}
. Which makes me think of another use for it in a different article where a terminological difference is being drawn between jargon terms sett and set, which I now realize will probably be pronounced identically by screen readers. But none of this calls for a new parameter. Maybe there is some kind of use for the proposed parameter, but these examples aren't it. A danger with such a parameter is that editors are apt to think it needs to be filled in, and would put unwise things in it on a regular basis. —
SMcCandlish
☏
¢ 😼 07:01, 23 October 2023 (UTC)
This template will occasionally fail to hide the text. It's not just within links, but I'm not sure what all scenarios cause it. It looks like in some situations the template styles are never given to the browser. I put the CSS inline in the sandbox, and the issues seem to go away.
This packs the presentation into the content though, Rjjiii ( talk) 23:08, 26 December 2023 (UTC)