Something that came up yesterday when I was discussing with User:Rexx about the new WikiFont, is how it will influence accessibility, since it is actually a 'character' that will have effects on screenreader software. I have no idea what the effect will be, so if we start using that, I very much encourage that we should go and find out and then document some of the knowledge we gather into it's style and usage recommendations guidelines.
DJ
I've heard that it will not, cc'ing Shahyar to weigh in, the same issue came up at the Zurich hackathon and I believe a satisfactory answer was arrived at that I don't know off the top of my head.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Sat, Aug 9, 2014 at 11:29 AM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> wrote:
Something that came up yesterday when I was discussing with User:Rexx about the new WikiFont, is how it will influence accessibility, since it is actually a 'character' that will have effects on screenreader software. I have no idea what the effect will be, so if we start using that, I very much encourage that we should go and find out and then document some of the knowledge we gather into it's style and usage recommendations guidelines.
DJ
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
The characters themselves are in the Unicode private use range and shouldn't be read out; but of course any use of them should be associated with a localized, readable title -- if there's not text alongside the icon already, there should be a title attribute or other appropriate marker.
We've been fixing this recently in the new iOS app where we found that we had to fix both the readable strings and the accessibility roles on some of our widgets.
-- brion
On Sat, Aug 9, 2014 at 11:29 AM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> wrote:
Something that came up yesterday when I was discussing with User:Rexx about the new WikiFont, is how it will influence accessibility, since it is actually a 'character' that will have effects on screenreader software. I have no idea what the effect will be, so if we start using that, I very much encourage that we should go and find out and then document some of the knowledge we gather into it's style and usage recommendations guidelines.
DJ
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Sat, Aug 9, 2014 at 12:39 PM, Brion Vibber bvibber@wikimedia.org wrote:
The characters themselves are in the Unicode private use range and shouldn't be read out; but of course any use of them should be associated with a localized, readable title -- if there's not text alongside the icon already, there should be a title attribute or other appropriate marker.
We've been fixing this recently in the new iOS app where we found that we had to fix both the readable strings and the accessibility roles on some of our widgets.
-- brion
Would it cause issues on screen-readers if instead of Unicode private use range, the existing unicode code points were used?
--Martijn
On Sat, Aug 9, 2014 at 11:29 AM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> wrote:
Something that came up yesterday when I was discussing with User:Rexx about the new WikiFont, is how it will influence accessibility, since it is actually a 'character' that will have effects on screenreader software. I have no idea what the effect will be, so if we start using that, I very much encourage that we should go and find out and then document some of the knowledge we gather into it's style and usage recommendations guidelines.
DJ
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
and shouldn't be read out;
Note the usage of shouldn't. Screen readers, browser and operating systems are notoriously bad at consistently and accurately implementing some of this stuff..
"Would it cause issues on screen-readers if instead of Unicode private use range, the existing unicode code points were used?"
Yes, that would be very bad, especially if they overlap with a-z.
DJ
On Wed, Aug 13, 2014 at 10:38 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sat, Aug 9, 2014 at 12:39 PM, Brion Vibber bvibber@wikimedia.org wrote:
The characters themselves are in the Unicode private use range and shouldn't be read out; but of course any use of them should be associated with a localized, readable title -- if there's not text alongside the icon already, there should be a title attribute or other appropriate marker.
We've been fixing this recently in the new iOS app where we found that we had to fix both the readable strings and the accessibility roles on some of our widgets.
-- brion
Would it cause issues on screen-readers if instead of Unicode private use range, the existing unicode code points were used?
--Martijn
On Sat, Aug 9, 2014 at 11:29 AM, Derk-Jan Hartman d.j.hartman+wmf_ml@gmail.com wrote:
Something that came up yesterday when I was discussing with User:Rexx about the new WikiFont, is how it will influence accessibility, since it is actually a 'character' that will have effects on screenreader software. I have no idea what the effect will be, so if we start using that, I very much encourage that we should go and find out and then document some of the knowledge we gather into it's style and usage recommendations guidelines.
DJ
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Wednesday, August 13, 2014, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> wrote:
and shouldn't be read out;
Note the usage of shouldn't. Screen readers, browser and operating systems are notoriously bad at consistently and accurately implementing some of this stuff..
"Would it cause issues on screen-readers if instead of Unicode private
use range, the existing unicode code points were used?"
Yes, that would be very bad, especially if they overlap with a-z.
DJ
I actually meant using the corresponding code points, like using 1f527 for a spanner icon, etc.
On Wed, Aug 13, 2014 at 10:38 AM, Martijn Hoekstra <martijnhoekstra@gmail.com javascript:;> wrote:
On Sat, Aug 9, 2014 at 12:39 PM, Brion Vibber <bvibber@wikimedia.org
javascript:;> wrote:
The characters themselves are in the Unicode private use range and shouldn't be read out; but of course any use of them should be
associated
with a localized, readable title -- if there's not text alongside the
icon
already, there should be a title attribute or other appropriate marker.
We've been fixing this recently in the new iOS app where we found that
we
had to fix both the readable strings and the accessibility roles on
some of
our widgets.
-- brion
Would it cause issues on screen-readers if instead of Unicode private use range, the existing unicode code points were used?
--Martijn
On Sat, Aug 9, 2014 at 11:29 AM, Derk-Jan Hartman <d.j.hartman+wmf_ml@gmail.com javascript:;> wrote:
Something that came up yesterday when I was discussing with User:Rexx about the new WikiFont, is how it will influence accessibility, since
it is
actually a 'character' that will have effects on screenreader
software. I
have no idea what the effect will be, so if we start using that, I
very much
encourage that we should go and find out and then document some of the knowledge we gather into it's style and usage recommendations
guidelines.
DJ
Design mailing list Design@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/design
As long as we use the following pattern for markup, we should be good accessibility-wise. The aria-hidden attribute hides the icon glyph from screen readers.
|<style> .icon-star:before { content: "★ "; } </style>
<span><span class="icon-star" aria-hidden="true"></span>Favorite</span> |
Code from http://filamentgroup.com/lab/bulletproof_icon_fonts.html
best, max @awesomephant
On Sat, Aug 9, 2014 at 11:39 AM, max max@koehler-kn.de wrote:
As long as we use the following pattern for markup, we should be good accessibility-wise. The aria-hidden attribute hides the icon glyph from screen readers.
<style> .icon-star:before { content: "★ "; } </style>
<span><span class="icon-star" aria-hidden="true"></span>Favorite</span>
Awesome, that should do the job for HTML usage yeah.
-- brion
Code from http://filamentgroup.com/lab/bulletproof_icon_fonts.html
best, max @awesomephant
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
That's exactly what I mean, we should make that part of the usage guidelines for the font, just as we have HTML examples in the kss styleguideline for mediawiki.ui. And we should have a similar example for icon-only cases without labels. etc etc.
Otherwise we will have three or four different and inconsistent approaches and it will be maintenance hell (perhaps we should even have factory api's for them, like with vform).
DJ
On 9 aug. 2014, at 11:42, Brion Vibber bvibber@wikimedia.org wrote:
On Sat, Aug 9, 2014 at 11:39 AM, max max@koehler-kn.de wrote: As long as we use the following pattern for markup, we should be good accessibility-wise. The aria-hidden attribute hides the icon glyph from screen readers.
<style> .icon-star:before { content: "★ "; } </style>
<span><span class="icon-star" aria-hidden="true"></span>Favorite</span>
Awesome, that should do the job for HTML usage yeah.
-- brion
Code from http://filamentgroup.com/lab/bulletproof_icon_fonts.html
best, max @awesomephant
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Sat, Aug 9, 2014 at 3:39 AM, max max@koehler-kn.de wrote:
As long as we use the following pattern for markup, we should be good accessibility-wise. The aria-hidden attribute hides the icon glyph from screen readers.
<style> .icon-star:before { content: "★ "; } </style>
<span><span class="icon-star" aria-hidden="true"></span>Favorite</span>
Flow action menus (hover or click the [...] in e.g. https://www.mediawiki.org/wiki/Talk:Sandbox ) are close to this
<a class="mw-ui-button mw-ui-quiet" href="/w/index.php?title=Topic:S08b4fijnlkf1n5s&action=edit-title&topic_revId=s08b4fil7q02dtvk" title="Edit title" ... > <span class="wikiglyph wikiglyph-pencil"></span> Edit title </a>
.wikiglyph { display: inline-block; font-family: 'WikiFont-Glyphs'; ... } .wikiglyph-pencil:before { content: "\e800"; }
No aria-hidden, but Brion said
The characters themselves are in the Unicode private use range and shouldn't be read out;
so do we need aria-hidden or not?
We should capture the recommendation in CSS comments that KSS turns into the living style guide.
(I think title text that simply duplicates the anchor's text is redundant, bug 69213).
Would be great if people could help fill out https://www.mediawiki.org/wiki/Icon_Standardisation I'm keen to document all the ways we currently use icons across MediaWiki and help us come up with a standard approach. Jon
On Tue, Aug 12, 2014 at 12:38 PM, S Page spage@wikimedia.org wrote:
On Sat, Aug 9, 2014 at 3:39 AM, max max@koehler-kn.de wrote:
As long as we use the following pattern for markup, we should be good accessibility-wise. The aria-hidden attribute hides the icon glyph from screen readers.
<style> .icon-star:before { content: "★ "; } </style>
<span><span class="icon-star" aria-hidden="true"></span>Favorite</span>
Flow action menus (hover or click the [...] in e.g. https://www.mediawiki.org/wiki/Talk:Sandbox ) are close to this
<a class="mw-ui-button mw-ui-quiet"href="/w/index.php?title=Topic:S08b4fijnlkf1n5s&action=edit-title&topic_revId=s08b4fil7q02dtvk" title="Edit title"
... > <span class="wikiglyph wikiglyph-pencil"></span> Edit title </a>.wikiglyph { display: inline-block; font-family: 'WikiFont-Glyphs';
...} .wikiglyph-pencil:before { content: "\e800"; }
No aria-hidden, but Brion said
The characters themselves are in the Unicode private use range and shouldn't be read out;
so do we need aria-hidden or not?
We should capture the recommendation in CSS comments that KSS turns into the living style guide.
(I think title text that simply duplicates the anchor's text is redundant, bug 69213).
-- =S Page Features engineer
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Just to make sure this q is covered:
A "speech bubble" icon can have a few (but very similar) representations to *screen readers*. For example:
A "speech bubble" icon next to talk page label means "talk page." A "speech bubble" icon next to a new talkpage notification means "new message."
Is there a way this is allowed?
mm
On Tue, Aug 12, 2014 at 9:25 PM, Jon Robson jdlrobson@gmail.com wrote:
Would be great if people could help fill out https://www.mediawiki.org/wiki/Icon_Standardisation I'm keen to document all the ways we currently use icons across MediaWiki and help us come up with a standard approach. Jon
On Tue, Aug 12, 2014 at 12:38 PM, S Page spage@wikimedia.org wrote:
On Sat, Aug 9, 2014 at 3:39 AM, max max@koehler-kn.de wrote:
As long as we use the following pattern for markup, we should be good accessibility-wise. The aria-hidden attribute hides the icon glyph from screen readers.
<style> .icon-star:before { content: "★ "; } </style>
<span><span class="icon-star" aria-hidden="true"></span>Favorite</span>
Flow action menus (hover or click the [...] in e.g. https://www.mediawiki.org/wiki/Talk:Sandbox ) are close to this
<a class="mw-ui-button mw-ui-quiet"href="/w/index.php?title=Topic:S08b4fijnlkf1n5s&action=edit-title&topic_revId=s08b4fil7q02dtvk"
title="Edit title" ... > <span class="wikiglyph wikiglyph-pencil"></span> Edit title </a>.wikiglyph { display: inline-block; font-family: 'WikiFont-Glyphs';
...} .wikiglyph-pencil:before { content: "\e800"; }
No aria-hidden, but Brion said
The characters themselves are in the Unicode private use range and shouldn't be read out;
so do we need aria-hidden or not?
We should capture the recommendation in CSS comments that KSS turns into
the
living style guide.
(I think title text that simply duplicates the anchor's text is
redundant,
bug 69213).
-- =S Page Features engineer
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Jon Robson
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Tue, Aug 12, 2014 at 1:59 PM, May Tee-Galloway mgalloway@wikimedia.org wrote:
Just to make sure this q is covered:
A "speech bubble" icon can have a few (but very similar) representations to *screen readers*. For example:
A "speech bubble" icon next to talk page label means "talk page." A "speech bubble" icon next to a new talkpage notification means "new message."
Is there a way this is allowed?
Sure.
If you're using WikiFont for the icon then it isn't "read" by screen readers, because it's in the Unicode private use range (and/or because someone adds aria-hidden=true). In your first example the talk page label may be clear enough; in the second if the nearby text isn't clear you would add title="new message on talk page" somewhere in the HTML, and possibly dive into http://www.w3.org/TR/wai-aria/ if you knew what you were doing :)
W dniu wtorek, 12 sierpnia 2014 May Tee-Galloway mgalloway@wikimedia.org napisał(a):
Just to make sure this q is covered:
A "speech bubble" icon can have a few (but very similar) representations to *screen readers*. For example:
A "speech bubble" icon next to talk page label means "talk page." A "speech bubble" icon next to a new talkpage notification means "new message."
Is there a way this is allowed?
Yes, just use the 'title' attribute on the closest clickable HTML element (this might be the icons's element itself, or often a surrounding <a> or <button>). This will also help readers on desktop devices who will be able to hover over the icon to read the title text to make sure they understood the icon right.
Thanks you both.
Great to know! I'll make sure we take this into consideration in during design decisions.
mm
On Tue, Aug 12, 2014 at 10:23 PM, Bartosz Dziewoński matma.rex@gmail.com wrote:
W dniu wtorek, 12 sierpnia 2014 May Tee-Galloway mgalloway@wikimedia.org napisał(a):
Just to make sure this q is covered:
A "speech bubble" icon can have a few (but very similar) representations to *screen readers*. For example:
A "speech bubble" icon next to talk page label means "talk page." A "speech bubble" icon next to a new talkpage notification means "new message."
Is there a way this is allowed?
Yes, just use the 'title' attribute on the closest clickable HTML element (this might be the icons's element itself, or often a surrounding <a> or <button>). This will also help readers on desktop devices who will be able to hover over the icon to read the title text to make sure they understood the icon right.
-- -- Matma Rex
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 08/09/2014 06:39 AM, max wrote:
Code from http://filamentgroup.com/lab/bulletproof_icon_fonts.html
I haven't looked into this further yet, but this article also discusses a lot of potential issues with icon fonts that I was not previously aware of.
They provide a MIT-licensed library (https://github.com/filamentgroup/a-font-garde) meant to help deal with this. We should look into these issues, see if they apply to us, and potentially use their library if appropriate.
Matt Flaschen
I'm chiming in late here, but our icons are in the PUA, and therefore have nothing to actually "read". aria-hidden is not necessary in this scenario; it is only needed when you are using unicode characters that can be read by a screen reader as something (eg. the caret glyph is read as "n-ary logical and"), but don't want it to because it is ornamental.
I have a test version https://gerrit.wikimedia.org/r/#/c/155612/ of something in Flow now, which allows us to just put the text inside the icon's element as plain text. This gets read fully by screen readers. The alternative to this would be to use <abbr> as the icon element, which gets its "title" attribute read by almost every reader.
--Shahyar
On Wed, Aug 13, 2014 at 3:30 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 08/09/2014 06:39 AM, max wrote:
Code from http://filamentgroup.com/lab/bulletproof_icon_fonts.html
I haven't looked into this further yet, but this article also discusses a lot of potential issues with icon fonts that I was not previously aware of.
They provide a MIT-licensed library (https://github.com/ filamentgroup/a-font-garde) meant to help deal with this. We should look into these issues, see if they apply to us, and potentially use their library if appropriate.
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 08/22/2014 02:17 PM, Shahyar Ghobadpour wrote:
I'm chiming in late here, but our icons are in the PUA, and therefore have nothing to actually "read". aria-hidden is not necessary in this scenario; it is only needed when you are using unicode characters that can be read by a screen reader as something (eg. the caret glyph is read as "n-ary logical and"), but don't want it to because it is ornamental.
One potential issue they discuss for PUA is:
"Using the PUA avoids semantic conflicts, but that still leaves us with visual ones. For example, some operating system default fonts define their own characters in the PUA. If any of your icons are mapped to a character with a default glyph and the font request doesn’t successfully complete, the default glyph will be shown."
I don't know how real an issue this is (they discuss an apparent real-world example on iOS). Might there be a noticeable number of failed font requests on mobile? Are we avoiding the no-go areas of the PUA?
Matt Flaschen
We can avoid the PUA areas that are commonly used for emoji, and start much higher up the PUA chain. That's the best we can do, and should work for pretty much everything.
--Shahyar
On Mon, Aug 25, 2014 at 5:35 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 08/22/2014 02:17 PM, Shahyar Ghobadpour wrote:
I'm chiming in late here, but our icons are in the PUA, and therefore have nothing to actually "read". aria-hidden is not necessary in this scenario; it is only needed when you are using unicode characters that can be read by a screen reader as something (eg. the caret glyph is read as "n-ary logical and"), but don't want it to because it is ornamental.
One potential issue they discuss for PUA is:
"Using the PUA avoids semantic conflicts, but that still leaves us with visual ones. For example, some operating system default fonts define their own characters in the PUA. If any of your icons are mapped to a character with a default glyph and the font request doesn’t successfully complete, the default glyph will be shown."
I don't know how real an issue this is (they discuss an apparent real-world example on iOS). Might there be a noticeable number of failed font requests on mobile? Are we avoiding the no-go areas of the PUA?
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
What does starting much higher up in the PUA chain means? PUA is PUA right?
On Tue, Sep 9, 2014 at 2:30 PM, Shahyar Ghobadpour < sghobadpour@wikimedia.org> wrote:
We can avoid the PUA areas that are commonly used for emoji, and start much higher up the PUA chain. That's the best we can do, and should work for pretty much everything.
--Shahyar
On Mon, Aug 25, 2014 at 5:35 PM, Matthew Flaschen <mflaschen@wikimedia.org
wrote:
On 08/22/2014 02:17 PM, Shahyar Ghobadpour wrote:
I'm chiming in late here, but our icons are in the PUA, and therefore have nothing to actually "read". aria-hidden is not necessary in this scenario; it is only needed when you are using unicode characters that can be read by a screen reader as something (eg. the caret glyph is read as "n-ary logical and"), but don't want it to because it is ornamental.
One potential issue they discuss for PUA is:
"Using the PUA avoids semantic conflicts, but that still leaves us with visual ones. For example, some operating system default fonts define their own characters in the PUA. If any of your icons are mapped to a character with a default glyph and the font request doesn’t successfully complete, the default glyph will be shown."
I don't know how real an issue this is (they discuss an apparent real-world example on iOS). Might there be a noticeable number of failed font requests on mobile? Are we avoiding the no-go areas of the PUA?
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
The concern is that some core OS fonts (iOS was mentioned specifically) use the first range of PUA, in this case for emoji. We can just start our offset way past that.
--Shahyar
On Tue, Sep 9, 2014 at 2:34 PM, May Tee-Galloway mgalloway@wikimedia.org wrote:
What does starting much higher up in the PUA chain means? PUA is PUA right?
On Tue, Sep 9, 2014 at 2:30 PM, Shahyar Ghobadpour < sghobadpour@wikimedia.org> wrote:
We can avoid the PUA areas that are commonly used for emoji, and start much higher up the PUA chain. That's the best we can do, and should work for pretty much everything.
--Shahyar
On Mon, Aug 25, 2014 at 5:35 PM, Matthew Flaschen < mflaschen@wikimedia.org> wrote:
On 08/22/2014 02:17 PM, Shahyar Ghobadpour wrote:
I'm chiming in late here, but our icons are in the PUA, and therefore have nothing to actually "read". aria-hidden is not necessary in this scenario; it is only needed when you are using unicode characters that can be read by a screen reader as something (eg. the caret glyph is read as "n-ary logical and"), but don't want it to because it is ornamental.
One potential issue they discuss for PUA is:
"Using the PUA avoids semantic conflicts, but that still leaves us with visual ones. For example, some operating system default fonts define their own characters in the PUA. If any of your icons are mapped to a character with a default glyph and the font request doesn’t successfully complete, the default glyph will be shown."
I don't know how real an issue this is (they discuss an apparent real-world example on iOS). Might there be a noticeable number of failed font requests on mobile? Are we avoiding the no-go areas of the PUA?
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design