Combining a DevExpress Windows Forms app that supports theming, including dark/high-contrast themes, and a WebView2 which isn't a part of the DevX and doesn't support theming leaves WebView2 in default "white" mode. A possibly acceptable solution would be to switch the WebView2 to high-contrast mode, the one that is activated when the OS is switched to high-contrast mode. Reading through the documentation and searching the internet, I am unable to find any clues if this is possible.
Is it possible to switch the WebView2 to high-contrast mode programmatically?
The Question is boxed but I am open to "outside" suggestions or ideas. We weren't able to find an acceptable CSS/JS solution since we are not in control of loaded HTML documents (although we can inject CSS and JS), and they heavily differ in style and content.
Related
I create applications, that are divorced from any native framework. All rendering happens in OpenGL, with a context provided by GLFW, all in C, with no framework to rely on supplying compatibility. As such, standard screen readers like NVDA have no chance of picking up information ( excluding OCR ) and my applications are an accessibility black hole.
How can I provide an interface for screen readers to cling unto? I presume this is a per OS thing... How would that be possible on Windows, Linux, BSD or even android? In the *NIX world, I presume this would be Desktop environment dependent...
I'm finding a lot of information on this, with a framework as a starting point, but have a hard time finding resources on how to do it from scratch.
I'm fully aware this is far beyond the capability of a sole developer and know, that writing programs by ignoring native interfaces is a common accessibility hole, which you are advised to avoid.
However, I have a tough time finding resources and jump-in points to explore this topic. Can someone point me in the right direction?
TL;DR: How to provide screen-reader compatibility from scratch. Not in detail - but conceptually.
As you have already well identified, your app is an accessibility blackhole because you are using a rendering engine.
It's basicly the same for OpenGL, SDL, or <canvas> on the web, or any library rendering something without specific accessibility support.
WE can talk about several possibilities:
Become an accessibility server. Under windows, it means doing the necessary so that your app provide accessible components on demand from UIA / IAccessible2 interface.
Use a well known GUI toolkits having accessibility support and their provieded accessibility API to make your app.
Directly talk to screen readers via their respective API in order to make them say something and/or show something on a connected braille display.
Do specific screen reader scripting
However, it doesnt stops there. Supporting screen readers isn't sufficient to make your app really accessible. You must also think about many other things.
1. Accessibility server, UIA, IAccessible2
This option is of course the best, because users of assistive technologies in general (not only screen readers) will feel right at home with a perfectly accessible app if you do your job correctly.
However, it's also by far the hardest since you have to reinvent everything. You must decompose your interface into components, tell which category of component each of them are (more commonly called roles), make callback to fetch values and descriptions, etc.
IF you are making web development, compare that with if you had to use ARIA everywhere because there's no defaults, no titles, no paragraphs, no input fields, no buttons, etc.
That's an huge job ! But if you do it really well, your app will be well accessible.
You may get code and ideas on how to do it by looking at open source GUI toolkits or browsers which all do it.
Of course, the API to use are different for each OS. UIA and IAccessible2 are for windows, but MacOS and several linux desktops also have OS-specific accessibility API that are based on the same root principles.
Note about terminology: the accessibility server or provider is your app or the GUI toolkit you are using, while the accessibility client or consumer is the scren reader (or others assistive tools).
2. Use a GUI toolkit with good accessibility support
By chance, you aren't obliged to reinvent the wheel, of course !
Many people did the job of point 1 above and it resulted in libraries commonly called GUI toolkits.
Some of them are known to generally produce well accessible apps, while others are known to produce totally inaccessible apps.
QT, WXWidgets and Java SWT are three of them with quite good accessibility support.
So you can quite a lot simplify the job by simply using one of them and their associated accessibility API. You will be saved from talking more or less directly to the OS with UIA/IAccessible2 and similar API on other platforms.
Be careful though, it isn't as easy as it seems: all components provided by GUI toolkits aren't necessarily all accessible under all platforms.
Some components may be accessible out of the box, some other need configuration and/or a few specific code on your side, and some are unaccessible no matter what.
Some are accessible under windows but not under MacOS or vice-versa.
For example, GTK is the first choice for linux under GNOME for making accessible apps, but GTK under windows give quite poor results. Another example: wxWidgets's DataView control is known to be good under MacOS, but it is emulated under windows and therefore much less accessible.
In case of doubt, the best is to test yourself under all combinations of OS and screen readers you intent to support.
Sadly, for a game, using a GUI toolkit is perhaps not a viable option, even if there exist OpenGL components capable of displaying a 3D scene.
Here come the third possibility.
3. Talk directly to screen readers
Several screen readers provide an API to make them speak, adjust some settings and/or show something on braille display. If you can't, or don't want to use a GUI toolkit, this might be a solution.
Jaws come with an API called FSAPI, NVDA with NVDA controller client. Apple also alow to control several aspects of VoiceOver programatically.
There are still several disadvantages, though:
You are specificly targetting some screen readers. People using another one, or another assistive tool than a screen reader (a screen magnifier for example), are all out of luc. Or you may multiply support for a big forest of different API for different products on different platforms.
All of these screen reader specific API support different things that may not be supported by others. There is no standards at all here.
Thinking about WCAG and how it would be transposed to desktop apps, in fact you are bypassing most best practices, which all recommand first above anything else to use well known standard component, and only customize when really necessary.
So this third possibility should ideally be used if, and only if, using a good GUI toolkit isn't possible, or if the accessibility of the used GUI toolkit isn't sufficient.
I'm the autohr of UniversalSpeech, a small library trying to unify direct talking with several screen readers.
You may have a look at it if you are interested.
4. Screen reader scripting
If your app isn't accessible alone, you may distribute screen reader specific scripts to users.
These scripts can be instructed to fetch information to give to the user, add additional keyboard shortcuts and several other things.
Jaws has its own scripting language, while NVDA scripts are developed with Python. AS far as I know, there's also scripting capabilities with VoiceOver under MacOS.
I gave you this fourth point for your information, but since you are starting from a completely inaccessible app, I wouldn't advise you to go that way.
In order for scripts to be able to do useful things, you must have a working accessible base. A script can help fixing small accessibility issues, but it's nearly impossible to turn a completly inaccessible app into an accessible one just with a script.
Additionally, you must distribute these scripts separately from your app, and users have to install them. It may be a difficulty for some people, depending on your target audience.
Beyond screen reader support
Screen reader support isn't everything.
This is beyond your question, so I won't enter into details, but you shouldn't forget about the following points if you really want to make an accessible app which isn't only accessible but also comfortable to use for a screen reader user.
This isn't at all an exhaustive list of additional things to watch out.
Keyboard navigation: most blind and many visually impaired aren't comfortable with the mouse and/or a touch screen. You must provide a full and consist way of using your app only with a keyboard, or, on mobile, only by standard touch gestures supported by the screen reader. Navigation should be as simple as possible, and should as much as you can conform to user preferences and general OS conventions (i.e. functions of tab, space, enter, etc.). This in turn implies to have a good structure of components.
Gamepad, motion sensors and other inputs: unless it's absolutely mandatory because it's your core concept, don't force the use of them and always allow a keyboard fallback
Visual appearance: as much as you can, you should use the settings/preferences defined at OS level for disposition, colors, contrasts, fonts, text size, dark mode, high contrast mode, etc. rather than using your own
Audio: don't output anything if the user can't reasonably expect any, make sure the volume can be changed at any time very easily, and if possible if it isn't against your core concept, always allow it to be paused, resumed, stopped and muted. Same reflection can apply to other outputs like vibration which you should always be able to disable.
Has anyone successfully gotten swfaddress to work with IE8 and above?
It seems that when using standards mode, swfaddress will appear to work fine in IE8 and IE9, however, once the user modifies the hashtag in the address bar, the history list becomes corrupted.
In cases where the user starts the application via the hash tag (http://myapp.com/#/test), and then visits another hash (http://myapp.com/#/test1), the history is never saved.
I have tried playing around with swfaddress 2.5 in the svn repository. Interestingly,
the code is similiar to JQuery Address (by the same author). I also note that JQuery Address suffers from the same problem.
If I turn on compatibility mode in IE, the swfaddress and JQuery Address works perfectly. I have been looking into how compatiblilty mode works, and it does not seem like it would modify or affect javascript execution.
Was anyone able to successfully solve this issue? If not are there any other deep linking libraries for flex or flash that contains all the feature sets of swfaddress?
After looking at libraries such JQuery Address, other JQuery state management plugins and even the BrowserManager that ships with Flash and Flex builder, I discovered that they all ran into the same issue as SwfAddress.
At the moment, SwfAddress offers that best features and comes with a .swc and .as files to easily interface with Flash and Flex applications.
Since the other javascript libraries ended up with the same problems, I have decided to stick with SwfAddress.
On a related note, the author has stated that he is no longer working on SwfAddress, so it would be cool if someone in the community can pick up on where it was left off.
I know similar questions have been closed for it being "impossible to answer objectively", but stick with me here.
I built a prototype in Adobe Flex, they (customers) liked it. Everything was fine until they later told me that iPads / iOS needs to be supported too.
I checked out Adobe's Packager for iPhone. We're evaluating that and we will know if it works out in a couple of days. (We need to get through Apple's red tape and certificates raj so this angle is delayed by a few days!)
There is a growing voice for using HTML5/Canvas as a technology platform itself. And despite being quite proficient in Flex, I think this makes sense.
I'm in need of a HTML5 library that can:
Render "widgets" i.e. containers with forms and components (this should be easy and possible using POHJC - Plain old HTML, JavaScript and CSS ;-) )
Provide a Tree like control for laying out some data
Provide a Canvas where data structures can be represented as basic shapes
Provide drag and drop capabilities between Trees, Buttons and Canvas
Provide some sort of Tab Navigator container (I guess JQuery works here)
Interact with back-end services (JSON/XML calls will be okay, but mapping directly with back-end entities will be awesome!)
Renders on latest versions of major browsers, Android OS and iOS (WebKit for mobile?)
Am I asking for too much?
I'm ready to give JQuery & JQuery UI a try.
I looked at Sencha / ExtJS but it seems we need to maintain two code bases one for normal browsers and the other for mobiles (is that correct?)
Are there any other JS libraries worth trying out?
My concerns areas are
Single code base, I don't want to suggest to them that multiple code bases for the client need to be maintained. That's a last resort option and would lead to complete ruling out of HTML5 with Flash apps and native apps being developed.
Canvas capabilities - I don't want to work with raw canvas and shape tags. This too is a last resort option. Is there any abstraction available?
Integration with back-end services, obviously I need some capability here!
Help me out. Communitywikify this if required.
Thanks,
Sri
How about trying Vaadin?
http://vaadin.com/comparison
I do construe its irrelevant to your question, but still this framework can help in great deal. I still use Flex and PHP as main base for many application, but actually fell in love with Vaadin and started using it for my new projects.
Grant Skinner the flash guru is working on a html5 libary. It has some features you requested. It is still in development.
The new Canvas element in HTML5 is powerful, but it can be difficult to work with. It has no internal concept of discrete display elements, so you are required to manage updates manually. The Easel Javascript library provides a full, hierarchical display list, a core interaction model, and helper classes to make working with Canvas much easier.
The libary is called easeljs, you can find it here : http://easeljs.com/
For the normal html and css manipulations without html canvas JQuery is very easy to learn.
I'm a blind developer who is considering learning Flex. According to this link when you compile a flex application with the defaults it isn't accessible to screen readers. Why is this, are there performance issues I should be aware of, or was this just an arbitrary choice Adobe made?
I think thats because it would increase the size of the compiled SWF, but I have no detailed information about this topic.
Simple Flex applications (like the samples) will benefit from having accessibility enabled. Unfortunately a large / complex Flex app requires a lot of effort in the design and implementation phases in order to be made properly accessible; it's not as simple as just enabling that one checkbox in Flex Builder. For this reason I'm sure Adobe decided to optimize the size of the SWF files generated by Flex Builder by disabling accessibility by default. More info on Flex accessibility can be found here:
http://www.adobe.com/accessibility/products/flex/
The ASP.NET dropdownlist control has an arrow that you can click to drop the list down, that color of the arrow is tied to the users windows color scheme. This is not convenient for me and I'll need a workaround. However, I'm wondering if anyone knows (or has a guess) the strategy behind making that dropdown arrow tie to the system color?
Behind the scenes, the Winforms controls use the Win32 controls that have been in existence since Windows 3.0 (or was 3.0 still 16 bit? I don't recall). There is a lot of legacy under the covers, and back in the days it seemed to make sense to do it that way.
I actually think it still make sense today to enforce some level of consistency between the user interfaces of all the applications of a platform.
Really, the style of your dropdownList depends on your navigator. Some navigators offer more support for this than others. The same ocurrs with checkboxes, for example.
Browsers are responsible for turning form input tags into user-interface controls. Internet Explorer and other browsers do this by using the operating system's user-interface controls. "A web page wants a <select>? We've got that control already!"
The problem you're probably experiencing, however, is that Internet Explorer has notoriously poor support for styling those controls - and especially the <select> control. Other modern browsers like FireFox and Chrome provide better support.
At this time, the only options for IE are (a) to abandon the <select> element in favor of some sort of javascript-based component or (b) to wait for IE8 and hope it has better style support. Since it is very, very difficult to find a javascript <select> implementation which provides robust keyboard support, many people choose to just live with ugly <select> boxes in IE for now - sacrificing style for usability and accessibility.
It has nothing to do with ASP.NET; you could view the same site on a Mac and it would look different. This is how windows displays that type of element. If you don't like it, then you will have to create your own. It's been done already.
Browsers, to a varying degree, pick up the users colour settings from the os, like any other application, so in the absense of any author specified settings, they are usually the default.
Be aware that once you start tweaking the styling for selects and other form elements, you need to be sure of giving a quite complete set of style rules, otherwise it can all go to hell in a handcart very quickly, just how quickly depends on the browser.