[Design] WikiFont and accessibility

[Derk-Jan Hartman]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140809/687936a1/attachment-0001.pgp>

[Jared Zimmerman]

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 [phone] \\ @jaredzimmerman <http://loo.ms/g0>



On Sat, Aug 9, 2014 at 11:29 AM, Derk-Jan Hartman <

Post by Derk-Jan Hartman
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140809/756a9403/attachment.html>

[Brion Vibber]

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 <

Post by Derk-Jan Hartman
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140809/227434dd/attachment.html>

[Martijn Hoekstra]

Post by Brion Vibber
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

Post by Brion Vibber
On Sat, Aug 9, 2014 at 11:29 AM, Derk-Jan Hartman <

Post by Derk-Jan Hartman
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140813/d86becf9/attachment.html>

[Derk-Jan Hartman]

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

Post by Brion Vibber
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

Post by Brion Vibber
On Sat, Aug 9, 2014 at 11:29 AM, Derk-Jan Hartman

Post by Derk-Jan Hartman
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

[Martijn Hoekstra]

On Wednesday, August 13, 2014, Derk-Jan Hartman <

Post by Derk-Jan Hartman

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.

Post by Derk-Jan Hartman
On Wed, Aug 13, 2014 at 10:38 AM, Martijn Hoekstra

On Sat, Aug 9, 2014 at 12:39 PM, Brion Vibber <bvibber at wikimedia.org

Post by Brion Vibber
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

Post by Brion Vibber
with a localized, readable title -- if there's not text alongside the

icon

Post by Brion Vibber
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

Post by Brion Vibber
had to fix both the readable strings and the accessibility roles on

some of

Post by Brion Vibber
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

Post by Brion Vibber
On Sat, Aug 9, 2014 at 11:29 AM, Derk-Jan Hartman

Post by Derk-Jan Hartman
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

Post by Brion Vibber

Post by Derk-Jan Hartman
actually a 'character' that will have effects on screenreader

software. I

Post by Brion Vibber

Post by Derk-Jan Hartman
have no idea what the effect will be, so if we start using that, I

very much

Post by Brion Vibber

Post by Derk-Jan Hartman
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.

Post by Brion Vibber

Post by Derk-Jan Hartman
DJ
_______________________________________________
Design mailing list
Design at lists.wikimedia.org <javascript:;>
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org <javascript:;>
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org <javascript:;>
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org <javascript:;>
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/design/attachments/20140822/deafd6d7/attachment.html>

[max]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140809/0cd43a0f/attachment.html>

[Brion Vibber]

Post by max
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

Post by max
Code from http://filamentgroup.com/lab/bulletproof_icon_fonts.html
best, max
@awesomephant
_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140809/38957ca8/attachment.html>

[Derk-Jan Hartman]

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

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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design
_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140809/de223095/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140809/de223095/attachment.pgp>

[S Page]

Post by max
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&amp;action=edit-title&amp;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

Post by max
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).

[Jon Robson]

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

Post by S Page

Post by max
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&amp;action=edit-title&amp;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

Post by max
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

[May Tee-Galloway]

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

Post by Jon Robson
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

Post by S Page

Post by max
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&amp;action=edit-title&amp;topic_revId=s08b4fil7q02dtvk"

Post by S Page
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

Post by max
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

Post by S Page
living style guide.
(I think title text that simply duplicates the anchor's text is

redundant,

Post by S Page
bug 69213).
--
=S Page Features engineer
_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140812/a7eb6e6b/attachment.html>

[S Page]

On Tue, Aug 12, 2014 at 1:59 PM, May Tee-Galloway <mgalloway at wikimedia.org>

A "speech bubble" icon can have a few (but very similar) representations
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 :)

[Bartosz Dziewoński]

W dniu wtorek, 12 sierpnia 2014 May Tee-Galloway <mgalloway at wikimedia.org>

A "speech bubble" icon can have a few (but very similar) representations
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.

[May Tee-Galloway]

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 at gmail.com>

Post by Bartosz Dziewoński
W dniu wtorek, 12 sierpnia 2014 May Tee-Galloway <mgalloway at wikimedia.org>

A "speech bubble" icon can have a few (but very similar) representations
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140812/0f604c80/attachment.html>

[Matthew Flaschen]

Post by max
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

[Shahyar Ghobadpour]

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 at wikimedia.org>

Post by max
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/design/attachments/20140822/76955000/attachment.html>

[Matthew Flaschen]

Post by Shahyar Ghobadpour
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

[Shahyar Ghobadpour]

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 at wikimedia.org>

Post by Matthew Flaschen

Post by Shahyar Ghobadpour
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.

"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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/design/attachments/20140909/33eb664a/attachment.html>

[May Tee-Galloway]

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 <

Post by Shahyar Ghobadpour
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 at wikimedia.org

Post by Matthew Flaschen

Post by Shahyar Ghobadpour
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.

"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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/design/attachments/20140909/96dae72c/attachment.html>

[Shahyar Ghobadpour]

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 at wikimedia.org>

Post by May Tee-Galloway
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 <

Post by Shahyar Ghobadpour
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 <

Post by Matthew Flaschen

Post by Shahyar Ghobadpour
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.

"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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/design/attachments/20140909/77f383f8/attachment.html>