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".....