compiz team mailing list archive

[crippled user <saddharmap@xxxxxxxxx>]

So it would seem that it could be Compiz - or Single application windows
or Both - and maybe "Yet More"!

I suspect the "Yet More" is the reality.

As I said Above "A Better reason for a Standard System Wide
Accessibility Policy I have never seen confirmed so quickly.

That policy need to inform all action from design and branding through
to coding - so that if there are multiple critical windows - they can be
identified, logged, checked and made to comply with accessibility
standards."

NOTE - what I have written in the second paragraph places the focus upon
the "Window" and on the desktop - which is where the user experiences
the "Impairment" of inaccessibility - The Virtual Staircase. Code below
that, and design issues are of lesser relevance and importance - and the
steps to resolve them should ensure that all elements of the Virtual
Staircase are removed. A single stair tread left hanging in mid air is a
hazard to all concerned and not just the user who suffers  Impairment.

So, if one part of the issue is in Compiz it may get resolved - but
individuals with responsibility else where may not know about it and
then refix what they see as a change they don't know about !

The change in basic accessibility standards has the air of a Root Cause
about it - and until that root cause is located, addressed and fixed, it
may well recur. I suspect that the Root Cause comes from Design
Philosophy and branding and is only them made manifest in code which
leaves basic accessibility features inaccessible and people impaired.

Is this a design bug - workflow bug, Not just a Coding Bug? A Design
Policy Bug?

Some may say that the Bug Tracker is not the place to raise that issue -
But I do believe it is. There is no other rational place to have the
matter on the record - and even as a learning venue.

For some bug tracking is about Burrowing Down into code - but it also
has to allow Burrowing UP to bigger issues too - else the Bug Tracker
simply functions to fix poor practices, decisions and outcomes (so often
not intended and unforseen) and embedding the negative  across the
platform and further a field long term. It also prevents people from
using the reports to learn in the widest sense about users and outcomes.

If some wish to call it ranting or improper use of the bug tracker -
they can have their opinion. Here in the bug tracker it does allow for
the complexity of issues across multiple packages - teams - groups to be
highlighted and possibly linked.

Discuss it else where is a cry - go blog else where - and discussion
which uses the actual bugs is better, as it does allow those who need
worked examples and not just abstract philosophy to utilise real world
examples as their learning tool. Some may only be interested in patches
- but some do have the capacity to elevate above basic patches to see
wider code issues - wider practice issues - so why should they be denied
the opportunity to do that?

If there are issues which are not simply code related but have a wider
implication across multiple work flows ( some where coding is not even a
factor ) It may be best for a suitable Tag to be developed for Bug
Tracker. "Multi-Discipline" or "Philosophy" may be options.

I see that "a11y" is a tag to raise accessibility and possibly gather it
into one place - but I also get the impression that this Tag is being
used as a comfort blanket by those not affected, to assume the issues do
not affect them and do have a home and are being addressed. The term
Ghetto comes to mind.

Gathering in one place has value - but can also cause a pooling effect -
corralling - which is about control and not about empowerment.

If there is a design issue it should be tagged "a11y-design" - and would
highlight how Branding and image can be affecting accessibility.

"a11y-desktop" would highlight how designed workflows on the desktop are
impacting accessibility.

"a11y" says there is an issue with accessibility - but it runs the risk
of just gathering bugs together and not having them addressed with wider
implications and underlying workflow - attitudes - impacts recognised
and resolved.

Some would see such tagging as having a negative impact upon them - but
if their activity and work is having an unforeseen and even unrecognised
none coding impact upon others .... It is a Bug that needs to be
addressed - and the issue may not be in buggy code, just how the overall
use of code has unforeseen consequences.

There is at present an apparent linear model to bug tracking and fixing
- which actually misses Parallel issues which may be Multi-track - with
some being far bigger than just code.  That runs the risk of a singular
code based bug fix in one area being applied - but subsequently undone
or impacted negatively in a parallel bug fix.

It acts as band-aids and sticky plasters providing repeated First Aide
when what is needed is correct diagnosis, management and possible cure.
It becomes repeated doses of fudge when high quality protein is
required. Fudge may keep you alive - but a quality diet allows you to
live.

The flat linear approach also misses out wider issues and none coding
matters which in the deign and delivery process are just as important -
and for some more important.

Having had to break down so many issues on accessibility with a view to
getting simple High Contrast schemes to work it needs at least;

1) High Contrast themes to be fixed - with Multiple Icon sets fixed to interface with them on the desktop - the indicator app - basically system wide from starting a live CD to having an installed system. 
2) Those to be verified against theaming in general  
3) Then all checked against Indicator-app
4) with that then having to be checked against basic window accessibility to allow Alt F8 to maximise ...
5) and point four impacts the ability to have a window to access a change of Cursor and alter it's size.

Looking at the bugs filed so far - only point 5 has been Prioritised and
assigned - "High - Canonical-Desktop-Team".

So it gets fixed - but may well still need to be revisited and tweaked
if-and-or when the more basic and underlying multiplicity of issues/bugs
are addressed.

... and yet basic accessibility should be working already. System Wide
to allow anyone to be test-driving and the Beta and even Bug Hunting.

The fact that Basic accessibility is not working is an issue that needs
to be addressed so that it is resolved and not a factor in any future
alpha - let alone beta.

That will not occur by simply patching code - there is a bigger issue
that needs to burrow it's way "UP" through the bug tracker and not down
- because if it is pushed down the Underlying Failures will just be
buried long term and keep coming back time and time again!

I have raised the issue that The Unity Launcher has to also work in High
Contrast - so where does the bug need to be filed on that one! You see -
the focus on making it all about a single package and burrow down bug
fix still misses the bigger picture and Unforeseen Consequences - and
that does identify the Bugs in underlying Philosophy!

So that needs to be tagged "A11y-bug-unity-laucher", and from what I can
see, that bug won't be fixed by tweaking all the code identified so far!

Bug report #964685 -

"6. When changing to high contrast the icons in the Unity launcher Icons
are "NOT" made high contrast - or at the very least have back lighting
Turned OFF to increase contrast. This is basic accessibility that should
be functional now. Orange Icon on an orange background is not high
contrast - and at the very least mouse over with high contrast selected
should turn off the back-lighting of the icon the mouse hovers over to
provide increased contrast and accessibility. Hack to turn off back-
lighting already available and should already be part of HIgh Contrast
themes to provide - well..... High Contrast."

Which packages need to be identified, named and reported as buggy to get
that issue addressed - and who needs to be altered to the
responsibility?

"A11y-Bug-Unity-Laucher"?

Or does it need to read "Unity-Laucher-Bug-A11y"?

Which takes precedence - the Code and the launcher - or the people who
need access to it.

Bugging Philosophy!

... and has anyone even looked at what happens to the Unity Launcher in
High Contrast - or High Contrast Inverted themes!

NOT Nice! ... and this is the Beta! 8^0

Screen shots to follow!

And should the high contrast themes automatically change the desktop
background and text colours to make the desktop well - high contrast?

Needs to all be re-tagged "Multi-Discipline", "Philosophy", "A11y-Bug-
Unity-Laucher", "Unity-Laucher-Bug-A11y", "a11y-design", "a11y-
desktop".....

-- 
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/966524

Title:
  it should be possible to maximize any window using (using F8)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/966524/+subscriptions