Opened 8 years ago
Last modified 8 months ago
#40486 new enhancement
Standard Themes: Logic for translated strings in connection with Screen Reader text can be improved
Reported by: | Presskopp | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Bundled Theme | Keywords: | dev-feedback |
Focuses: | Cc: |
Description
There are 2 strings including:
screen-reader-text"> "%s"
1)
Continue reading<span class="screen-reader-text"> "%s"</span>
&
2)
Edit<span class="screen-reader-text"> "%s"</span>
In german (as an example, I assume this happens too in other languages) the syntax for 1) needs to be reversed like that:
<span class="screen-reader-text">"%s"</span> weiterlesen
2) gets:
<span class="screen-reader-text">„%s“</span> bearbeiten
which is correct for Screen Reader Users, but it should rather be capitalized in both cases so the button text doesn't start lowercase, see screenshot.
We could now capitalize the strings in translation, but there must be a better solution!?
PS:
Yes, the quotation marks in our translation also needs a little attention, but that's not part of the ticket ;-)
Attachments (1)
Change History (12)
#3
@
2 years ago
- Summary changed from Twenty Seventeen: Logic for translated strings in connection with Screen Reader text can be improved to Standard Themes: Logic for translated strings in connection with Screen Reader text can be improved
..turns out this also happens in Twenty Sixteen and Twenty Nineteen.
#4
@
21 months ago
I can confirm that this is still happening. It came up in a support thread.
#5
@
13 months ago
@joedolson Hi! This ticket brings up theme "continue reading" links and "edit post" links that combine a text with a visually hidden post title.
In the themes that are mentioned in the ticket, the post title is inside double quotes (").
Example:
the_content( sprintf( /* translators: %s: Post title. Only visible to screen readers. */ __( 'Continue reading<span class="screen-reader-text"> "%s"</span>', 'twentyseventeen' ), get_the_title() ) );
Is there any accessibility benefit to placing the post title within quotes?
The themes are Twenty Sixteen, Twenty Seventeen, and Twenty Nineteen, so it is not consistent across all default themes.
For example Twenty Fifteen uses the following code:
the_content( sprintf( /* translators: %s: Post title. Only visible to screen readers. */ __( 'Continue reading %s', 'twentyfifteen' ), the_title( '<span class="screen-reader-text">', '</span>', false ) ) );
#6
@
13 months ago
No, there's no advantage to wrapping the title in quotation punctuation in the screen reader text. Some screen readers might read them out or interpret them as a pause, but that's heavily dependent on screen reader configuration and voice synthesizer. I wouldn't consider it an advantage in any case; just a difference. If a pause is desired, then more consistent approach would be to use a colon, e.g.:
the_content( sprintf( /* translators: %s: Post title. Only visible to screen readers. */ __( 'Continue reading<span class="screen-reader-text">: %s</span>', 'twentyseventeen' ), get_the_title() ) );
#7
@
11 months ago
@Presskopp For these text strings where the order needs to be changed during translation, it is difficult for someone who is not a native German speaker to propose a new markup.
I wonder if it would be an improvement if there were two separate texts. If the visible link text was "Edit", but there was an aria label with the full context: "Edit %post title".
#8
@
11 months ago
@poena
Either the texts should be both exactly the same or they needed to be separated, yes. As we can see it doesn't work if 2 strings get concatenated and make a part of that "screen reader only"
#9
@
11 months ago
I don't understand what "the texts should be both exactly the same" means.
But I also don't understand why
<span class="screen-reader-text">„%s“</span> Bearbeiten
would be a problem if Bearbeiten needs to be capitalized. And that capitalization is added by the translator. I think I am missing the point. The screen reader software is not going to read it incorrectly just because it is capitalized?
Would this fix it?
and
It doesn't address the capitalization problem though.