Hi,
Since I having eye disabilities I use the enabled black based High-Contrast-Mode (high-contrast-#1 theme/design) on Windows 7 and Windows 10.
Since the installer and the updater are strictly "branded" with white background images, there is already a problem, since white as background is not that "mandatory" (MSDN rules) high-contrast support.
On Windows 7 the text in the installer or at the last updater screen is yellow and so yellow on white background image.
On Windows 10 it is white texto n white background image.
To test it on your self:
- use LeftShift+LeftAlt+PrintScr to enable or diable the high-contrast-mode
- switch through the high-contrast designs to test the visual results.
I really would appreciate, if some changes will take place to support accessibility helpers (MSDN: mandatory accessibility support).
Best regards,
Martin
P.S.: Desktop Zoom is mostly ignored, too on my Windows 7 office desktop.
The platform's installer and updater/app store as well as the portableapps.com installers are written in NSIS. This is a widely-used open source installer (Firefox, 7-Zip, and lots of other projects use it). You'd need to ask them about full compatibility with high contrast themes.
Side Note: The main bits of the installer, updater, and app store do work with the high contrast theme already, at least on Windows 10. I think I may be able to at least manually detect the high contrast theme and force the white text to black in the affected areas with a bit of work. For note, the affected areas are the welcome/finish pages as well as the headers throughout.
Sometimes, the impossible can become possible, if you're awesome!
Sorry, but do I understand it correctly?
Someone decides to include a white big bitmap and to use white backgrounds for "branding" and I should ask the Installer people to change this?
Hhm - you are not that wrong, but if they would disable your branding, because of high-contrast-mode - automatically - would you be glad of it? I would!
But at first I would ask the configurator of the installer to think about the design to be mandatory, or if this design could be changed!
I had similar "Tickets" with other software developers and companies and most of them simply changed their installer configuration to have smaller bitmaps with original branding and much bigger system color using window background. This way system color using text was always visible and readable.
But eventually you are right. NSIS & Co should automatically switch off branding, design to support handicapped people in the most efficient way.
About the "main bits".
If installer work mostly with high-contrast, than it is quiet good.
But if (initial and/or final) messages are unreadable - due to branding/corporate design - than accepting mostly high-contrast-mode is not enough.
Martin Lemburg, Berlin / Germany
It's not an image. The actual window background itself is set to forced white and doesn't pick up what Windows says theme-wise. The welcome and finish page have an image on the left (for text modes that read left to right) and then no image the rest of the window, that's all just window controls and form background. The header image isn't full width either, it's just the right-most 150px (again for text modes that read left to right). The left part of the header is just form background and window controls.
So, it's not something we designed or set. It doesn't matter what images we use, even if they were just 100% black. The actual NSIS installer works the same way. As does a basic MUI one.
So, I'm trying to figure out a way to detect whether a high contrast theme is enabled or not. And then if so, which one is enabled. Unfortunately, it's more complicated than can be accomplished within NSIS scripting easily as you have to create a HIGHCONTRAST structure (which NSIS isn't designed for), run some code on it, and feed it to a specific Windows API which will tell you whether high contrast is enabled or not once you then compare the compound result to a specific flag. But, that won't tell you which theme is enabled. Because it could be white (or another color) text on black... or it could be black text on a white background. So, that won't help us in terms of trying to manually work around the NSIS hard coding of color.
What I may do for now is force the text on welcome, finish, and the header to be black since the background is stuck as white. It won't match your selected theme, but it will at least be visible.
Sometimes, the impossible can become possible, if you're awesome!
Thanks for your explaining response.
No matter if I'm wrong with my assumptions or not. Some support teams changed their installers to be more "compatible" by using the system background color or like you suggested a defined black font color to prevent the usage of system colors for window text on white background.
I'm looking forward to have more readable information - even if it is only "Finished updating".
Thanks in n advance!
Best regards,
Martin
Martin Lemburg, Berlin / Germany
Other installers like MSIs aren't affected. I'm not sure about InnoSetup offhand. NSIS itself seems to be hard coding those two areas (header and welcome/finish bg) to white for some reason, even though it picks up the Windows color settings for everything else. NSIS itself seems to respond in real time to both turning on and off high contrast. It's just those two areas that are hard coded to white, even though the text on those areas is responding to the change. Very odd.
I'm working on hard coding them to black text with scripting as each of the 'pages' of the installer loads. It won't match the selected Windows theme if you use a black background (though it would be fine if you select black text on white, of course) but it will at least be visible. It would become invisible if you switched high contrast on while the installer already had a page loaded, but as soon as you went forward or back a page it would be visible again.
Sometimes, the impossible can become possible, if you're awesome!
I've changed the subject and labeled this a bug for tracking purposes.
For any developers following along, here is the code to run on a page's show function to force the header to be black text sop it's visible on the forced white background (including a PUSH/POP to ensure we don't dirty any variables):
I can't get something similar working on welcome/finish yet even when using the appropriate window handle.
UPDATE2: With the welcome pages in conjunction with MUI2, the following code in a custom show handlers will force black text on a white background:
And with finish, it's a bit more complicated:
Unfortunately, you can't properly set checkbox fore color. Only the background. So, this is an annoying hack to set the checkbox background to 50% gray. This ensures it's somewhat visible for both the standard white or yellow text as well as the less common black text high contrast themes.
I still can't yet determine high contrast use within NSIS itself but can determine it in the platform. So the platform can pass it along to apps as well as to backup/restore and app store/updater when necessary. The next platform release will set an environment variable called PortableApps.comHighContrast. To pull it into an NSIS variable, define it and then put this in .onInit:
I'll continue updating as I make more progress.
UPDATE3: I've refined the header hack into an easily-inserted macro that works for both MUI version 1 and 2. Including this macro will let you just call ${PageHeaderHackForHighContrast} in your show function:
Sometimes, the impossible can become possible, if you're awesome!
This is fixed and worked around in today's release of the PortableApps.com Installer 3.5.2. The welcome and finish screens as well as the header are forced to black text regardless of Windows' settings to be visible on the background which is locked to white by NSIS itself. There is an issue with the one or two check boxes on the final screen (run, read log, etc) where they will not accept a changed color and will use Windows' colors. In this instance, it will look for an environment variable called PortableApps.comHighContrast and if it is set to true, it will force a gray background behind both checkboxes and text. The next release of the PA.c Platform will set this environment variable automatically based on your Windows theme setting. You can force this mode on by setting that environment variable to true at the Windows level or you can test it by creating a batch file called test.bat or similar next to the PortableApps.comInstaller_3.5.2.paf.exe installer with these lines in it:
The above-mentioned changes affect both the PortableApps.com Installer's generation wizard as well as all the app installers it generates. Today's updated apps all use this new installer so should be visible in high contrast now.
I will continue updating the platform for the next release with similar changes to the PA.c App Store/Updater, Backup/Restore utility, and the platform's installer as well. This bug will remain open until then.
Sometimes, the impossible can become possible, if you're awesome!
The environment variable PortableApps.comHighContrast is now set in the PortableApps.com Platform stable 14.4.2 and later as well as the 15.0 Beta 1 and later releases. This will allow installers and tools that are aware of it (like the PortableApps.com Installer generator and the PA.c Installers themselves) to automatically utilize it to fix checkboxes.
Sometimes, the impossible can become possible, if you're awesome!
This should all be fixed in the new 15 Beta 2 release of the platform I just posted. I made the fixes to the updater/app store, backup, and restore. The bug will remain open pending stable release.
Sometimes, the impossible can become possible, if you're awesome!
The above-mentioned fixes have all landed in the stable channel with the 15.0 release.
Sometimes, the impossible can become possible, if you're awesome!