Accessibility issues in 2.6.5

Topics: Controls
Jun 11, 2013 at 9:14 PM
Hi all,
I tried putting in an issue a few months ago, but it got no votes and no responses. I am a blind user who relies completely on the output of text-to-speech software in order to use a computer at all. As a result, I cannot use the mouse and have to use the keyboard at all times as well. The problem here is that in the administration panel of 2.6, the "tools" link beside each blog for editing the title and what not as well as beside say, each extension for enabling, disabling, and so on, does not seem to be keyboard focusable; I use the enter key to equal a double click on the link and it just sits there. I end up having to use my screen reader's cursor routing mechanisms in order to attempt to simulate a double click of the mouse as well, but that doesn't seem to work either. What can I do in order to fix this? Or would it be easier if I demonstrated this on video or something like that? Does anyone know whether this is fixed in the latest version? If so, then I can attempt to get it integrated into the latest Sueetie framework; that's the problem though, I'm not very good at coding; i'm just learning. I'd love to discuss this further; I think that this issue hinders blind administrators from performing the most basic administrative duties on their blogs. The project is fantastic in every other way though. Please reply to this if you want to discuss it or if you need more information; i'd really like to see this fixed. Thanks all for listening.
Jun 11, 2013 at 10:25 PM
We need to evaluate what the solution in this case would be. Simply adding tab index to UL tag probably won't work and there needs to be JavaScript changes as well. I'll try to do a mockup with simple HTML page and send it to you to check if it will work.
Jun 11, 2013 at 10:59 PM

Okay thanks; I’d love for this to be resolved; I figured it had something to do with JavaScript, but I wasn’t totally sure.

Jun 11, 2013 at 11:06 PM
Hi Ghromebuster, RTur
My daughter is blind, so accessibility is an issue close to heart.
RTur, if you wouldn't mind sending me a copy of the mockup HTML page as well, I'd be honored to contribute whatever I can to arrive at a solution.

Jun 11, 2013 at 11:10 PM

I’ll be honest when I tell you that my HTML stinks, but I’ll do what I can with the page. Though I don’t have any of the code-behind files on my server since it’s running on my web site. I mean, I’d love to have the latest version running in there, but that’s up to the Suetie people, and they charge hefty fees for that. (the Sueetie Community needs to step up, or the projects needs to be taken away from, or bought off of, the current leader.)

Jun 12, 2013 at 12:13 AM
Hi Chromebuster,
Don't worry about the HTML or test setup, I can test it and have my daughter verify, if she can use it then you should be able to use it.
Ideally a solution that works seamlessly for sighted users and keyboard users should be feasible, if RTur is agreeable to this, then we can get back to you with an end result.

I can't speak for sueetie, other that I know that the founder is one of the good guys, so if it's fixed in BE then it should be good for sueetie.

Jun 12, 2013 at 1:52 AM

He is one of the good guys, but open source is broken in that community. But anyway, I shouldn’t be babbling about that here. But remember that you should make the distinction between sighted users and blind users, not sighted users and keyboard users; keystrokes work for sighted folken as often as they do for us, so the problem is definitely something to do with how the application sees the keyboard input, I think. Either the keystroke is getting trapped for some reason, or the application just doesn’t recognize it.

Jun 12, 2013 at 11:05 AM
You're right, it wasn't my intention to make that distinction, I guess I was just thinking specifically. I should have said something that works for both mouse and keyboard users.

You are also right about the benefits of the keyboard to all users. I still remember using Lotus 123 from the DOS days when everything was keyboard driven and how fast that was to use, and that's still true for key combinations in GUI programs now.

I think maybe in my eagerness to lend a hand, I've been a little clumsy with my words, so by that measure, best I steer clear.

As a matter of curiosity however, under the appearance tab in the BE 2.6 admin panel, how are you navigating between Extensions, Themes and Widgets?
Jun 12, 2013 at 2:33 PM

Well, those links up top there thankfully are clickable, it’s just the tools links near each one that don’t seem to have keyboard focusable elements at all. Like I said, I figure it’s a JavaScript thing; when done carelessly, JavaScript can do nothing more than hinder accessibility. Not to say that you guys are careless for is an awesome project, but in some cases, it’s all JavaScripts fault LOL.

Jun 12, 2013 at 3:55 PM
Save this file, unzip it in any folder on your computer and open "tabs.htm" in the web browser.
It is stripped down page from admin saved as HTML so you don't have to worry about back-end, it should work locally.
I added tab index to the tools menu and set it to open on focus by adding CSS style.
Try it and see if it works for you, I'm not sure if you can tab through opened list items. If not we'll need to find another way.
Jun 12, 2013 at 4:04 PM

I’ll tell you. That was odd. I opened it from Internet Explorer one time when I hit the open instead of the save button, and when I used the enter key to click the tools link, an edit link came up seemingly under it which is what is supposed to happen, isn’t it? Then I went to do the same thing with the edit link that showed up. Nothing happened; the link is still not seemingly keyboard focusable. Then I saved the file and tried again. I used the same method to try and open up the tools link under there and nothing happened at all.

Jun 12, 2013 at 4:15 PM
IE can be tricky handling local files, like asking for "allow blocked content" etc. Try to use FireFox or Chrome, if that works we'll take care of IE.
Jun 12, 2013 at 4:27 PM

It didn’t ask for anything wonky like that when I did it, but I’ll try firefox if only it would respond on my computer; that’s been difficult to come buy lately.

Jun 12, 2013 at 4:54 PM

Firefox does the same thing in terms of being able to access the tools link via the keyboard. I use the enter key as an alternative to a true double click like I said, and then in firefox, after doing that on the tools link anywhere on the page, it is marked as a visited link but nothing comes up under it.

Jun 12, 2013 at 5:20 PM
Ok, so it let you tab to the list, opens it up but not letting you tab through the list items where you can hit "enter" to do the "click". Let me check what else can be done.
Jun 12, 2013 at 5:44 PM

It didn’t let me do anything. Just clicked the link, it was marked as visited, but no list of anything came up under it.

Jun 12, 2013 at 5:52 PM
You probably doing something different then. That zip file should have HTML page and folder with supporting files, CSS and JavaScripts, may be you didn't get them. I'll set it up on the server later tonight so you'll just need to get to the page without downloading anything. And I still need to get another solution regardless, this clearly does not let me tab over the list.
Jun 12, 2013 at 5:55 PM

I have all of them; don’t worry. I unzipped the folder, opened the html file and then used enter to click the tools links on that page to see if it would make any difference and all it did was mark the link as visited instead of letting me see what is underneath it.

Jun 12, 2013 at 9:59 PM
Two options that might be worth considering.
  1. Use a select element for the tools button and use the onchange event to action.
    The classic accessibility problem with this is that using the cursor keys to change the selected option triggers the onchange event immediately, so you can never get past the first option, unless you use JavaScript to alter this behaviour. I use an adapted version of this solution to provide keyboard accessible select elements and it seems to work well(uses the enter key to action the selected option).
  2. Continue to use the current lists for the button, but instead of having the nested list with display set to none(screen readers don't like this) give the nested list a class that positions it off screen and then remove that class when the parent anchor receives focus(sighted keyboard users) or hover for mouse users. Toggle class back when leaving the control.
Jun 12, 2013 at 10:25 PM
I'm looking at this one, just don't have time right now to get it done.
Jun 12, 2013 at 10:52 PM
That looks good, just been looking at this one as well.
I can have a play around with the stripped down admin page in the morning(UK time), hopefully get something sorted if you're pushed for time.
Jun 12, 2013 at 11:01 PM

All I can say is, this looks fantastic. Thanks guys.

Jun 13, 2013 at 12:51 AM
Seems to be working well using the code example from MU.
Will check over it in the morning and tidy up.
I removed the IE 6 stuff, can that stay out or is it still being supported?
Jun 13, 2013 at 10:36 AM
New test files, unzip and open as before.
Jun 13, 2013 at 1:56 PM

This is interesting; what seems to be happening is that in Internet Explorer 10, the links aren’t keyboard focusable and they just sit there as before, but in Firefox, they actually work, and the “hello” dialogues appear as they are supposed to. Now the only screen reader I’ve been trying is JAWS for Windows version 14 (the latest one), but if there are issues with JAWS, then chances are there are issues with other screen readers like System Access. There were before, at least.

Jun 13, 2013 at 2:14 PM
When I run this in IE 10, I get a message asking if I should allow blocked content.
I have to answer yes, otherwise the JavaScript will not run and the links will not be keyboard focusable.
This can be taken care of, but for test purposes, you will need to allow the script to run.
Jun 13, 2013 at 2:31 PM

Interesting. I’ll have to check that over here on my end, though I don’t recall a blocked content prompt coming up. That in no way means it didn’t. I’ll check the information bar the next time I try it.

Jun 13, 2013 at 2:49 PM
I'm installing Jaws 14 at the moment.
It's possible that you may not have got that "block content" message, it should appear when you fire up the browser and go to the test page, but it may depend on the browser configuration. Looking at that now.
Jun 13, 2013 at 3:01 PM

No, I definitely did get it, I just wasn’t paying attention to it, so I didn’t see it at first, but then the next time I checked it out, I unblocked the content and the JavaScript ran fine. That works beautifully now, that’s for sure. Those links work very nicely for those who prefer use of the keyboard, which is what I was aiming for. But you can still keep the list hidden as long as somebody clicks or uses the enter key to activate the link, but the goal is to make sure that the “tools” links remain keyboard accessible like they ar now. What I notice is that right now, there is no need to activate them at all since the “edit” and “delete” links are sitting there in the open. The issue now is going to be ensuring that it enters the next version of BlogEngine and then on another note, me trying to have the latest version of it integrated into the latest Sueetie Framework. But the issue is going to be getting the developer to realize the importance of accessibility long enough to break away from his “no bucks, no buck rogers” policy that he has set up, for I can’t afford to pay 2500 dollars.

Jun 13, 2013 at 3:26 PM
Andy, this works great in FF and issue with IE is likely due to local file policy, so I wouldn't spend any time fixing it and rather try it directly in BE server side. I'll integrate this into BE code this coming weekend when I have a bit more of a breathing space. If you want to do it yourself and submit a patch or fork that will work too :)
I haven't look into your solution yet, but I suspect this is CSS/JS and probably can be applied to 2.6 that Sueetie uses without upgrade.
Jun 13, 2013 at 4:20 PM
Edited Jun 13, 2013 at 4:22 PM
Never done a fork before, but more than happy to make changes in 2.6 and 2.8 and provide link to amended files(can do this before the weekends out, if that's OK).
There's just a few extra lines of code in the CSS/JS. I'm not sure how Sueetie is setup, but with a bit of luck the 2.6 files can just be copied over to the server.
Jun 13, 2013 at 6:04 PM

What about the 2.8 files? (I’m strong enough to perform the upgrade myself I think if someone shows me what to do if it is not a simple copy over of files). I’m getting better at it, but considering the Sueetie founder is charging so much money for it, it’s not because he can, now is it? There must be something very involved with it, like I said, if you guys know how it’s done, I have Visual Studio here, and I can do it if someone tells me how. My goal is to get to the latest version with these accessibility changes built right in. It seems silly for you to have to maintain two different branches because of this.

From: Andy_McKay []
Sent: Thursday, June 13, 2013 11:21 AM
To: Katherine Moss
Subject: Re: Accessibility issues in 2.6.5 [blogengine:446727]

From: Andy_McKay

Never done a fork before, but more than happy to make changes in 2.6 and 2.8 and provide link to amended files(can do this before the weekends out, if that's OK).
There's just a few extra lines of code in the CSS/JS. I'm not sure how sweetie is setup, but with a bit of luck the 2.6 files can just be copied over to the server.

Jun 14, 2013 at 12:09 AM
Edited Jun 14, 2013 at 12:12 AM
RTur, Looking for some direction.
In the mockup test page a call to the accessible dropdown JavaScript could be added quite simply to document.ready in the admin.js and good to go. The real files are different, looks like the admin tables are added via templates and populated from a load function in each admin aspx page. To make sure everything still works I tested by adding a delay to the load for the dropdown function to allow time for page loading to complete before trying to access the elements.

In admin.js
$(window).load(function () {    
    setTimeout(function () {
    }, 500); //Could increase time  
This works, it's simple and clean, but I'm not comfortable relying on that. Would it be better to add a call to accessible dropdown at the end of each load function defined in admin.js that needs it(if that makes sense)?

Katherine, don't know anything about the upgrade process for Sueetie, but all being well should have BE 2.6 files for you tomorrow, it's something.
A CSS file and a JS file, very surprised if that breaks anything.
Jun 14, 2013 at 12:36 AM

Okay great. I’ll have to talk to Dave Burke about the upgrade process. But I’ll be sure to insert said files when I get back from my appointments tomorrow; great job guys, and keep me updated! I can’t tell you how much I appreciate your listening to me; it’s not every day that an open source project supports accessibility, in fact, some turn away and say “it’s open source, fix it yourself”. You guys are wicked understanding, so I appreciate that. I wonder why my issue on this very topic that I reported earlier didn’t get any votes though; very strange.

Jun 14, 2013 at 3:06 AM
Edited Jun 14, 2013 at 3:08 AM
I guess you could add call just before end of body tag in admin.master:
    <script type="text/javascript">
Or make it separate script and use defer/async to load it after HTML done. I'm not a huge fan of timeouts and try to avoid them unless no other way.
Jun 14, 2013 at 12:49 PM
Both sensible suggestions that you would expect to work, I didn't manage to get them working.
Might be something to do with the way the admin pages are assembled or it might just be me.

Here's what I did get working, doesn't use timeout.


Katherine, I merged the admin folder from the 2.6 archive file into the admin folder of a fresh copy of BE 2.6, replacing files as prompted.
This seems to work fine, so perhaps this will tide you over until Sueetie updates with the latest version of BE.

Jun 14, 2013 at 1:06 PM

Okay thanks. Though you bet that I’m going to fight this one tooth and nail; I’m going to ask him to show me what to do to update this considering in my opinion, accessibility fixes are a very, very compelling reason to update, and if Dave Burke doesn’t care, then he should not be developing web frameworks and charging people through the nose per feature.