High contrast icons blocking Fedora releases - do we really want to?

[Adam Williamson]

Hi, folks. So something came up in passing at the QA meeting today which
we agreed to discuss here.

We added a criterion for Fedora 21 Final:

"All applications installed by default in Fedora Workstation must comply
with each MUST and MUST NOT guideline in the Applications and Launchers
policy."

https://fedoraproject.org/wiki/Workstation/Guidelines/Applications_and_La...

that policy includes this:

"App launchers MUST have a unique[3] 128×128 launcher icon with an alpha
channel and a matching High Contrast icon."

so effectively any default-installed app in Workstation lacking a high
contrast icon blocks the release of Fedora. We do indeed have two such
bugs on the current blocker list:

https://bugzilla.redhat.com/show_bug.cgi?id=1160499
https://bugzilla.redhat.com/show_bug.cgi?id=1130794

someone at the meeting wondered whether we really want to block Fedora
releases for this, and mclasen said:

<mclasen> I don't think it justifies blocking the release, tbh
<mclasen> but it is nice to have some pressure for getting those gaps
closed

We're quite strict about not using the blocker process for this kind of
thing these days, and I still think that's the best policy. One of the
problems we identified with the old blocker process back around F12-F14,
when we solidified the current process and added the "freeze
exception" (at the time, "nice to have") concept was that (ab)using the
blocker list as a list of 'priority' bugs meant no-one was really clear
on what bugs would actually literally block the release, and what bugs
would just be hand-waved when it came time to decide whether we shipped.

Since then we've stuck to the policy that only bugs we would actually
delay the release for go on the blocker list, and I think that's worked
out well and we should try to stick with it.

So with that in mind, can I ask if we really want to block Fedora
releases on high-contrast icons? If the consensus is 'yes', then fine,
no need for action. If 'no', then we'd need to amend either the release
criterion or the Applications and Launchers policy in some way - for
instance:

"App launchers MUST have a unique[3] 128×128 launcher icon with an alpha
channel and SHOULD include a matching High Contrast icon."
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Michael Catanzaro]

On Mon, 2014-11-24 at 11:52 -0800, Adam Williamson wrote:
>  Since then we've stuck to the policy that only bugs we would
> actually
>  delay the release for go on the blocker list, and I think that's
>  worked
>  out well and we should try to stick with it. 
I absolutely agree with this.

>  So with that in mind, can I ask if we really want to block Fedora
>  releases on high-contrast icons? If the consensus is 'yes', then fine,
>  no need for action.  
Well, the blocker is not that "app X needs a HC icon," the blocker is
"app X with no HC icon is installed by default," which really should
never be the last blocker left before final release since the affected
app can be dropped if no icon materializes.

For F21, we obviously can't (or don't want to) remove anaconda, or
fedora-welcome, or setroubleshoot (well honestly I was kind of hoping
for that one to be removed :), so this time around the criterion was a
credible threat to delaying the release. But that's just because the
criterion is brand new. (Maybe it was a mistake for it to have applied
to existing apps.) Going forward, this criterion only prevents us from
introducing *new* applications to the default install if they would
cause our high contrast coverage to regress; it will never again impact
critical apps like anaconda (unless perhaps an icon is lost by accident,
which ought to be easily-fixable). So when this issue occurs again, it
will be because we decided to add a new app to the default install (or
the app somehow was added inadvertently), and the WG will be able to
close the blocker bug by dropping the app from the default install,
rather than risk delaying the release. (Or it could choose to delay the
release if the app is really insanely desirable.)

So my opinion is yes, blocking on HC icons is fine. But if we don't want
to, we can just change the relevant point in the applications and
launchers policy from MUST to SHOULD.

Michael

[Chris Murphy]

On Mon, Nov 24, 2014 at 12:52 PM, Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:

>  "App launchers MUST have a unique[3] 128×128 launcher icon with
> an alpha
>  channel and SHOULD include a matching High Contrast icon." 
I'd like to think a matching high contrast icon can be done inside an
hour, and if not, then not knowing anything else yes I'd block on it.

The requirement is not new, and it is reasonable. I'm not an
accessibility expert, and I don't know if Fedora is explicitly
targeting those with vision impairment and how well we do across the
board with respect to accessibility: i.e. if our accessibility grade
is a poor/below average, then it's probably not block worthy; if
Fedora otherwise scores well in accessibility then it's worth blocking
on.

SETroubleshoot is probably a required application so we can't give it
the boot. If we could, then I'd say "24 hours to hand over the high
contrast icon, or the application is off the Fedora 21 train".

For Fedora 22, there needs to be a more formalized application
qualifications being met before the first Beta TC. Something like, all
applications are out, until they've ticked off the entire list of
requirements; and only then do they appear as default applications.


-- 
Chris Murphy

[Máirín Duffy]

On 11/24/2014 04:37 PM, Chris Murphy wrote:
>  On Mon, Nov 24, 2014 at 12:52 PM, Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
>
> > "App launchers MUST have a unique[3] 128×128 launcher icon with an alpha
> > channel and SHOULD include a matching High Contrast icon."
>
>  I'd like to think a matching high contrast icon can be done inside an
>  hour, and if not, then not knowing anything else yes I'd block on it. 
Wouldn't that be nice if things were that simple?

~m

[Adam Williamson]

On Mon, 2014-11-24 at 14:37 -0700, Chris Murphy wrote:

>  The requirement is not new, and it is reasonable. 
Factual point, it is new. We dropped the old polish criteria several
releases ago, and even when we had them, they did not require high
contrast icons, only that there was a default icon of sufficiently high
resolution (the exact wording was "All Applications listed in the system
menus (or equivalent) must have icons which have a consistent appearance
and sufficiently high resolution to avoid appearing blurry").
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Chris Murphy]

On Tue, Nov 25, 2014 at 10:37 AM, Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  On Mon, 2014-11-24 at 14:37 -0700, Chris Murphy wrote:
>
> > The requirement is not new, and it is reasonable.
>
>  Factual point, it is new. We dropped the old polish criteria several
>  releases ago, and even when we had them, they did not require high
>  contrast icons, only that there was a default icon of sufficiently high
>  resolution (the exact wording was "All Applications listed in the system
>  menus (or equivalent) must have icons which have a consistent appearance
>  and sufficiently high resolution to avoid appearing blurry"). 
OK "new this release" vs "new this week"; I'm pretty much
assuming
most everything is new for Fedora 21. But the originally cited
guidelines are not new this week, they were approved three months ago.
That's what I meant by not new.

-- 
Chris Murphy

[Rex Dieter]

Adam Williamson wrote:

>  "App launchers MUST have a unique[3] 128×128 launcher icon with
> an alpha
>  channel and a matching High Contrast icon." 
Fwiw, I personally disagree with the last part about requiring a matching HC 
icon (which can easily be fixed in an update).

That said, the policy only affects the *menu*, and I don't consider either 
anaconda or setroubleshoot to be typical applications, so -1 to considering 
either bug a blocker.

-- Rex

[Peter Robinson]

On Tue, Nov 25, 2014 at 2:30 PM, Rex Dieter <rdieter(a)math.unl.edu&gt; wrote:
>  Adam Williamson wrote:
>
> > "App launchers MUST have a unique[3] 128×128 launcher icon with an alpha
> > channel and a matching High Contrast icon."
>
>  Fwiw, I personally disagree with the last part about requiring a matching HC
>  icon (which can easily be fixed in an update). 
I would argue that if it's not visible to a partially sighted person
during install how are they to actually get the release installed.
Unfortunately for someone that actually needs high contrast to make a
system usable it's not really something they can do without to begin
with and update later, it's not like some other features that can be
fixed easily with an update (like say a web cam or a peripheral
driver) because it likely affects the persons ability to actually use
anything from the outset.

Peter

[Elad Alfassa]

On Tue, Nov 25, 2014 at 4:37 PM, Peter Robinson <pbrobinson(a)gmail.com&gt;
wrote:

>  On Tue, Nov 25, 2014 at 2:30 PM, Rex Dieter
> <rdieter(a)math.unl.edu&gt; wrote:
>  > Adam Williamson wrote:
>  >
>  >> "App launchers MUST have a unique[3] 128×128 launcher icon with an alpha
>  >> channel and a matching High Contrast icon."
>  >
>  > Fwiw, I personally disagree with the last part about requiring a
>  matching HC
>  > icon (which can easily be fixed in an update).
>
>  I would argue that if it's not visible to a partially sighted person
>  during install how are they to actually get the release installed.
>  Unfortunately for someone that actually needs high contrast to make a
>  system usable it's not really something they can do without to begin
>  with and update later, it's not like some other features that can be
>  fixed easily with an update (like say a web cam or a peripheral
>  driver) because it likely affects the persons ability to actually use
>  anything from the outset.
>
>  Peter
>  --
>  desktop mailing list
>  desktop(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/desktop
>  

Right, but the problem is that with the current way Fedora is designed it's
going to be hard for a visually impaired person (or anyone requiting *any*
kind of accessibility features to actually install the OS, since enabling
those options is hidden deep in the menus.

I'd say that if we want to make the installation process itself accessible,
we need to have an option to turn on accessibility features directly from
fedora-welcome some how, but this needs some careful design work.

For Fedora 21 I don't see a real reason to put these bugs as blockers. To
see a high contrast icon you'd need to first find the accesibility settings
panel and click on the right switch, which is probably not easy for people
who need high contrast. Once we figure out a way to easily enable high
contrast before installation, then it will be critical to have a proper
icon. As for setroubleshoot, it's not critical during installation so it
can always be updated later.
-- 
-Elad Alfassa.

[Matthias Clasen]

On Tue, 2014-11-25 at 16:45 +0200, Elad Alfassa wrote:
>  Right, but the problem is that with the current way Fedora is
> designed
>  it's going to be hard for a visually impaired person (or anyone
>  requiting *any* kind of accessibility features to actually install the
>  OS, since enabling those options is hidden deep in the menus. 
It is not 'deep in the menus'. We don't have submenus, so nothing can be
'deep' in there anymore. And we should the universal access icon on the
login screen and during initial-setup precisely to make sure that a11y
is just one click away. I'm not sure if we do the same on the
uninstalled live image. If not, we probably should.

We also have a keyboard shortcuts for the most important ATs. I think at
least for the screen reader, the binding is the same that Windows has,
for increased familiarity.

[Chris Murphy]

On Tue, Nov 25, 2014 at 7:45 AM, Elad Alfassa <elad(a)fedoraproject.org&gt; wrote:

>  I'd say that if we want to make the installation process itself
> accessible,
>  we need to have an option to turn on accessibility features directly from
>  fedora-welcome some how, but this needs some careful design work. 
I agree with this. Perhaps the installer UI should be, I'm not sure of
a proper term, but "passably accessible" from the start, with a
straightforward way to enable an enhanced accessibility mode that
passes through to the installation.


>  For Fedora 21 I don't see a real reason to put these bugs as
> blockers. To
>  see a high contrast icon you'd need to first find the accesibility settings
>  panel and click on the right switch, which is probably not easy for people
>  who need high contrast. Once we figure out a way to easily enable high
>  contrast before installation, then it will be critical to have a proper
>  icon. As for setroubleshoot, it's not critical during installation so it can
>  always be updated later. 
Seems reasonable. So some additional granularity in the requirements
is needed, to carve out what things will/won't block.


-- 
Chris Murphy

[Máirín Duffy]

On 11/25/2014 09:37 AM, Peter Robinson wrote:
>  I would argue that if it's not visible to a partially sighted
> person
>  during install how are they to actually get the release installed. 
Anaconda has a high-contrast icon (it was always there, for some reason 
it wasn't displaying at first) that works now. So accessibility in terms 
of launching the installer itself isn't an issue.

The remaining problem is the welcome app doesn't have one. This is 
because the icon it uses is the Fedora logo and for various reasons we 
cannot produce a high contrast version of the Fedora logo. I don't think 
you can actually launch the welcome app anyway so it's an issue of it 
not having an icon in the dash / taskbar.

~m

[Elad Alfassa]

On Tue, Nov 25, 2014 at 4:56 PM, Máirín Duffy <duffy(a)fedoraproject.org&gt;
wrote:

>  On 11/25/2014 09:37 AM, Peter Robinson wrote:
>
> > I would argue that if it's not visible to a partially sighted person
> > during install how are they to actually get the release installed.
> >
>
>  Anaconda has a high-contrast icon (it was always there, for some reason it
>  wasn't displaying at first) that works now. So accessibility in terms of
>  launching the installer itself isn't an issue.
>
>  The remaining problem is the welcome app doesn't have one. This is because
>  the icon it uses is the Fedora logo and for various reasons we cannot
>  produce a high contrast version of the Fedora logo. I don't think you can
>  actually launch the welcome app anyway so it's an issue of it not having an
>  icon in the dash / taskbar.
>
>  ~m
>
>  --
>  desktop mailing list
>  desktop(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/desktop
>  
Oh, I understand.

Well,  in that case I think it shouldn't be a blocker at all. The launcher
policy was written about user-visible launchers. The welcome app is not one
of these, so the policy should not apply.

-- 
-Elad Alfassa.