We're using node-webkit for packaging an app made with HTML5 and js. Everything has been working well but now when we try to read the content using a screen reader (Apple VoiceOver or Jaws), the content seems inaccessible.
The screen reader is able to read the window's buttons and the window's title but can't read the HTML inside the app. Actually it doesn't work with the sample page that came out of the box with node-webkit so is not a problem of our app.
Any ideas or alternatives? Thanks!
Each platform (OS) like Windows, OS X and Linux(es) (and Android and iOS and countless others on mobile) has its own accessibility API. For example Windows Automation API on Windows 7 and 8 (open source softwares use IAccessible2 but it seems to be a useful extra layer to it. Whatever)
A software like a browser must communicate with the OS what it is doing via this API (it could be an email client, a spreadsheet, a file explorer, etc).
The OS will filter (examples: if it's not the active window, if a system thing happens like removal of a USB key or new notification)
This accessibility API will then inform assistive technologies (AT) like a screen reader (SR) of what's happening. A SR being a complex software with user configuration, it'll also filter, adapt, output via a speech synthesis and/or a Braille display, etc from what it was fed.
Though I'm only accustomed to web accessibility and not in anything related to software, browsers, APIs and their internal working (so I could be very wrong, sorry) I guess the communication related to accessibility from "WebKit" to the OS (and there's "WebKit" on Windows, OS X, maybe still Linux, etc) is managed by Chrome the software (and vanilla Chromium the software from Chromium the project), NOT WebKit the rendering engine. node-webkit is made around Chromium but does it pass along the messages related to accessibility API? If it does or can, you should have the same accessibility as in Chromium (good luck with that, compared to Firefox and IE). If it doesn't, that's a black box.
One would then need to add all this accessibility API management to make it work! Maybe it's just an option in node-webkit?
If you want to verify if anything goes out of a software related to an accessibility API, you can test with aViewer from The Paciello Group.
May be related: Blink accessibility (Chromium project)
Related
is there a client based javascript way to detect Eddystone-URL beacons directly from the Chrome browser in iOS?
I know Chrome has the widget for the today view wich works fine, but I need to detect new Eddystones without pulling down the notifcations window.
Say a user clicks on a link provided by the widget, gets redirected to the Chrome app, does stuff, walks around and gets in range from another beacon.
Right now he would have to pull down the tab again to receive the new URI. But I need some sort of notification from within the Browser.
I hope you get the idea.
Thanks in advance!
Cheers
p.
Unfortunately, this is not possible. Understand that Chrome for iOS is just a thin app around the standard native iOS UIWebView, so there is nothing you can do in JavaScript that you cannot do in Safari. And Apple does not implemented any JavaScript bindings to the CoreBluetooth APIs that would be needed to detect Eddystone-URL beacons. The bottleneck is more of an iOS restriction than a Chrome browser one.
Note that this is not true for the Chrome browser on other platforms, notably ChromeOS, which does provide such JavaScript APIs.
I've developed interactive content for a client ( VR Objects ) using javascript and Flash (if needed) that they now want to distribute to prospective customers via a flash drive. That makes it local content causing security issues especially with IE. Actually there doesn't seem to be much problem with any browser except IE. True, IE displays the "allow blocked content" button but they fear that is too complicated or scary. And on IE11 in Win 8.1 it still may not work.
The development environment I use has a way around that for testing using an "embedded web server" although all that seems to do is produce a localhost address such as http://localhost:60331/wyj-01xn/output/surfacide_flash.html. Paste that in the URL bar of any browser on the same machine and you are good. Try it on another machine and no go. So I gather the port address and whatever the /wyj-01xn/ is about are machine specific. Another possible problem -- it may not work easily with IE11 on Win8.1, but I don't personally have that setup to test.
QUESTION: Is there a way I can produce this same functionality for my client, distributed along with the content on the flash drive, without the need to install some special software (local web server) on each client computer??? The current workaround is to tell customers they should us any browser except IE. Client isn't happy.
You could distribute your webpages along with a portable Nginx server, or wrapped inside a Node-webkit or AppJS package.
I have seen several of these question from 1-2 years ago about Android pre-4.0. I want to ask this again for Android 4+.
I have a galaxy s3 running 4.3 and when I click on a pdf link it downloads the document rather than opening it in the browser.
I am building a website and it will have links to pdf documents. The desired behavior when one of my users clicks on the pdf link on their Android device is for the pdf document to just open like it would on a desktop browser.
Is there anything I can do to achieve this functionality, or does Android still not support this?
I cannot control the device that a user is using, so I'm looking for a solution that would achieve this functionality in as many cases as possible.
The stock browser does not support native viewing of PDFs. You can however redirect the link to google docs and view internally that way. To do this, launch your implicit view intent, as I suspect you are already doing, but prepend the URI with "https://docs.google.com/gview?url=" and Google will take care of the rest
Alternately, there are a few libraries that you will see linked around SO, but from what I saw while researching, most are proprietary and cost and even then they might not work 100%. Google docs is free and works as often as Google does, which given that this is their platform you have to imagine they make certain their service works close to 100% of the time.
it downloads the document rather than opening it in the browser.
"it" is a Web browser. There are many Web browsers for Android. A Web browser can do whatever it wants when the user clicks on a link to a PDF file.
The desired behavior when one of my users clicks on the pdf link on their Android device is for the pdf document to just open like it would on a desktop browser.
That is not the behavior of all desktop browsers, particularly depending upon user configuration (e.g., browser extensions). A desktop Web browser, like a mobile Web browser, is welcome to do whatever it wants when the user clicks on a link to a PDF file.
does Android still not support this?
Android is an OS. Android neither supports nor does not support this. Web browser applications will or will not support what you want.
I cannot control the device that a user is using, so I'm looking for a solution that would achieve this functionality in as many cases as possible.
You are welcome to test a variety of Android Web browsers, see if there are any that behave the way you like, and suggest to your users that you would prefer that they use those browsers. Your users, in turn, are welcome to honor or ignore your request.
Or, as Chris M points out, you are welcome to not show a PDF at all, but rather redirect the user to some URL that processes the PDF and renders it in some other way.
I am presently working on website (Java EE). One of the requirements is to not let the client to open anything else other than the browser. After a lot of search I got the following results :
Change the policy of the OS.
Write some batch/c/c++ program which will intercept all the keyboard and mouse events not letting the user open anything else.
PS : It should work on windows and IE 7 or above only. The other OS and browsers need not be considered. This software is made only for intranet, so I already have control on the client machines if I have to run something.
My question is .. is there anything else I can do which will reduce the work needed on the client side or on the program which I have to write??
This is very OS specific I'd say. Windows, I believe, has APIs related to finding open windows. You could find all open windows and close them. In your application's main loop you can detect if any windows are open then close them.
Perhaps mac and ubuntu have something similar.
This might be a good place to start looking: http://msdn.microsoft.com/en-us/library/ms633497%28VS.85%29.aspx
I have no idea how to use it though.
You'll need something more powerful than javascript to communicate with your application that is monitoring the user's desktop. You may want to look at connecting JS to Silverlight then having the client download something upon opening the browser that is also similar to silverlight or .net. Then you can have them all communicate possibly.
You can set IE to be the shell process (a registry key) instead of explorer.exe, and then run IE in kiosk mode, and then disable task manager via policy (to prevent new processes).
What languages/techniques are used for letting the web browser interact with the desktop, e.g. dragging files to the web browser, dragging files from web browser to desktop, and maybe more features that I'm not aware of.
I think flash and silverlight allows you to do that but I'm not sure.
Does javascript do this?
It depends on what you mean by "interact". Browsers can't really interact with the desktop except for choosing files to upload or choosing places to download files. There's a good reason for that.
ActiveX controls on Windows permitted IE to interact with the desktop, which turned out to be a gigantic security nightmare. Even Microsoft has backed off of that approach now.
If you want to interact with the user's computer, you should try AIR, which is an executable application outside of the browser.