Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make A Dark Room accessible to the blind. #70

Open
amirrajan opened this issue Dec 6, 2013 · 20 comments
Open

Make A Dark Room accessible to the blind. #70

amirrajan opened this issue Dec 6, 2013 · 20 comments

Comments

@amirrajan
Copy link
Contributor

There are blind (yes, blind) people playing the iOS version of the game. And they are loving it. ADR is in a unique position to actually bring a great game to the vision impaired.

@groteworld
Copy link
Member

I've been thinking a lot about this issue and how it can be remedied. How does the iOS version handle takeoff that the visually impaired can successfully navigate it? I haven't played the mobile version.

@amirrajan
Copy link
Contributor Author

I'm working on that myself. It's a bit easier on the iOS version because they can touch the screen and have different UI controls read out information to them.

Most of the complaints I've gotten so far have been around the map:

  • What's around me
  • How can I get back to the village
  • How far are things

@Continuities
Copy link
Contributor

I actually feel kind of bad about this issue. At first glance, ADR appears
to be a fairly accessible game. Once the world map is unlocked, however,
I'm totally at a loss for how to maintain accessibility. This, I'm sure,
leaves a lot of people stuck with no way to progress. I'd love to address
this, but I have no idea how. Any ideas would definitely be appreciated.

On 9 December 2013 13:32, Amir Rajan notifications@github.com wrote:

I'm working on that myself. It's a bit easier on the iOS version because
they can touch the screen and have different UI controls read out
information to them.

Most of the complaints I've gotten so far have been around the map:

  • What's around me
  • How can I get back to the village
  • How far are things


Reply to this email directly or view it on GitHubhttps://github.com/Continuities/adarkroom/issues/70#issuecomment-30158435
.

@amirrajan
Copy link
Contributor Author

I'm making good progress on the iOS version. And hopefully will have an accessible version out by the end of the month. I'll post what I've learned from that here.

@amirrajan
Copy link
Contributor Author

What I know so far is that the reading speed of the voice over devices used are set to an extremely fast rate.

@groteworld
Copy link
Member

One idea I can think of is showing that data that @amirrajan pointed out in the top bar or somewhere.

Super quick example:
example map
(Forgive my incomplete map. I restarted my game.)

@amirrajan
Copy link
Contributor Author

It may just be easier to serve up another view all together. Though some work will have to be put in to unravel DOM manipulation from the engine itself. The problem with the current view is that the readers will literally read every ascii character.

@Continuities
Copy link
Contributor

Yeah, this is pretty much why the idea of accessibility fills my heart with
dread.

On 9 December 2013 14:18, Amir Rajan notifications@github.com wrote:

It may just be easier to serve up another view all together. Though some
work will have to be put in to unravel DOM manipulation for the engine
itself. The problem with the current view is that the readers will
literally read every ascii character.


Reply to this email directly or view it on GitHubhttps://github.com/Continuities/adarkroom/issues/70#issuecomment-30163890
.

@jernaumorat
Copy link

If much, or any more is to be changed or added to this game, it needs to be rewritten; as you've said before, Angular would make management of the DOM so much easier, and make fundamental changes like this more feasible. Unfortunately, at this stage of the game's lifecycle, I just don't see that happening.

@amirrajan
Copy link
Contributor Author

Agreed. Too much would need to be done.

Sent from my iPhone

On Dec 31, 2013, at 6:12 AM, Nathan Munk notifications@github.com wrote:

If much, or any more is to be changed or added to this game, it needs to be rewritten; as you've said before, Angular would make management of the DOM so much easier, and make fundamental changes like this more feasible. Unfortunately, at this stage of the game's lifecycle, I just don't see that happening.


Reply to this email directly or view it on GitHub.

@sukiletxe
Copy link

Hello,
I found A Dark Room through Portableapps and decided to give it a try. I found out that it was playable, although it had some issues (dynamic content not read automatically, clickable elements, no headings). That was until today, when I discovered the compass and the outside world. (Did I mention I'm blind?)
In case you are interested in implementing accessibility, I can give you some ideas. I don't know how to write JS, but I can more or less understand it.
I would say that a separate view is required for this to work properly. That is to say, the original map would be hidden with aria-hidden=true, showing a blank (or dependent on the hidden one) div, with role=application. Then, keyboard shortcuts could be introduced to query the necessary information from the map, and this information could be communicated to the screen reader using ARIA. I don't know if this makes sense to you or if it's possible, but I believe it's logical enough.

As for the other issues I've encountered:

  • Dynamic content: aria-live could be used, though it may be too chatty at times, especially with supplies.
  • Clickable eleements and lack of headings: The most straightforward method is to use the standard elements instead of (or outside) the clickable spans (links or buttons and headings). ARIA roles can also be used.

Thank you very much for this great game.

@groteworld
Copy link
Member

@sukiletxe Thank you for sharing your experience! You have definitely helped me think of some ideas for combatting this issue. I'll do some research on a few of the tips that you gave us, and at the very least, make some of the smaller changes.

Thank you again!

@sukiletxe
Copy link

sukiletxe commented Jun 13, 2016 via email

@groteworld groteworld reopened this Jun 14, 2016
@lrq3000
Copy link

lrq3000 commented Aug 21, 2016

I don't know much about accessible interfaces, but why not allow the character to be moved by point-and-click? Just let users control a cursor moving square by square, and allow them to target a square to move the character there. Additionally, the UI could show the closest point of interest in all directions, like:

      T 4
       ^
A 3 <  B  > H 2
       v
      A 3

Home: 6 South-East

In this instance, the cursor is over a square with POI type B which is exactly 3 squares right and 3 squares up from A, and A is the closest POI in both left and down directions, hence why the repeat. Also, Home: x always give the distance from currently highlighted square to the base, because that's a crucial information (along with water and food, the rest is not so important, so I guess they should be make <strong> or something like that). The path could be computed with a simple algorithm such as Djikstra algo, or A* breadth-first if you want something faster (but in any case, you don't need to walk through the whole map, just find the closest point to each cardinal direction) with Manhattan distance.

If an enemy is encountered, a message box could be shown to ask if user want to continue with some infos like health and stuff. Also of course, the battles would need to be turn-by-turn, because I hardly see how a blindhelper reading software could be as fast as some enemies attacks.

Also an alternative HUD that would be super accessible without any loss of information:

Home at 6 squares South-East, Current: B, left: A at 3 squares, down: A at 3 squares, right: H at 2 squares, up: T at 4 squares

Just my 2cents about a possible alternative view for blind people,

@gitupofftheflooranddosomework
Copy link
Contributor

I do like this issue, how could we do this?

@Simon818
Copy link

I'm playing this on iOS and really enjoy it so far, so just wanted to say thanks for everything that's been done there.
One thing I notice is that the web version is a lot less accessible for whatever reason. The main issue is that none of the buttons actually have a button role, and the percentage bars (for instance, to indicate when you can stoke the fire or check traps) are not readable. Can this be fixed? I would think adding a role to the buttons and a screen-reader-only (invisible) text label for the percentages would do it. I have no clue about the world map on the web. I'm likely going to be playing it on iOS for the most part unless this issue looks like it's likely to happen, and then I'm happy to test and poke around in the DOM more.

I'm an accessibility tester and super newbie coder, hoping to get to a point where I can start doing pull requests for this kind of thing myself but I'm not there yet. Thank you for your consideration.

@gitupofftheflooranddosomework
Copy link
Contributor

@Simon818
Copy link

Sorry for the confusion.

I was using the native iOS app on iOS and that has a lot of accessibility built in. I didn't realize there was a web version for quite some time, and was using it on Windows. I wouldn't call it inaccessible, but there's almost no meaningful HTML markup on the page, which means shortcut keys for moving to next/previous control don't work and keyboard navigation (tab, shift+tab, etc.) also doesn't work. Screen reader users rely on the ability to do things like moving to the next heading or button, so not having these control types defined on the page causes the interface to feel extremely clunky.

@gitupofftheflooranddosomework
Copy link
Contributor

@Simon818
Copy link

That's good to know. I saw that it was linked on the page, so didn't realize the two projects were maintained by separate developers.

I mostly mentioned the iOS app because of the extra accessibility though; I'm here because I'm interested in using this web version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants