Waching daily Jan 1 2019

>> Really quick.

First of all, thank you for coming and let me quickly introduce

myself.

My name is Michelle Martin.

I'm a Software Engineer at MetalPop Games right now.

I actually have been working in the video games industry for over 10 years.

I started out just like most programmers did.

Started when I was about 11 and then never stopped and I think that

is a biography I share with most coders in this industry.

So, I did the classical route of studying computer science and started at a big game

studio.

I worked on first person shooters and the first triple-A games I worked on

was the crisis serious.

I've also worked with Unreal, I've worked with Unity and right now I'm working

at my own company which is MetalPop Games.

We are really small, we're just five people right now

but see us in a couple of years please.

We've also, created the Unity Accessibility Plugin,

which is a plugin for Unity, which is a game engine, to make

games made with Unity accessible.

It essentially recreates screen reader abilities inside of Unity because unfortunately,

unity doesn't work for technical reasons that are perfectly

sound with any screen readers that are out there today.

So, yes, let's talk accessibility and what this talk is actually

about.

So, I made accessible game myself in my free time,

then I went back to my company and helped them,

well my company has made our game not our first game but our game, first accessible

game.

And then, last year actually also started contracting for other game studios

to help them make their games accessible

and I learned a heck of a lot mostly by doing them wrong in the first place and this

is sort of a talk about the biggest, the lessons I learned and maybe I

can help you avoid some of those mistakes.

First thing I learned and I do really want to

pass on is interface conventions.

Yes, blind people have them too.

Then the bare minimum I did and probably everybody will do to make a game accessible.

And then to go a step beyond that and actually make the accessibility to shine,

make it good and make the game fun to play.

And let me know if I'm too fast.

Alright.

So, yes, I have a couple of games that I worked on that are accessible.

I created this match three sort of Candy Crush game as my first one,

then the company MetalPop games, we release Crafting Kingdom,

resulted in idle strategy game and I've worked on a couple other in

the past and this is what I'm going to talk about.

So, I have made, hang on, no, it is the right slide, sorry.

So, when I started out making my very first game,

I did everything wrong Karen said not to do.

I actually did not ask a single-blind person, I didn't consult with anybody,

I did not get any feedback.

I had this great idea how my interface was going to work and it was a mobile game and

it included long tabs and dragging to the side and circular pop-up menus and it

was awesome.

Until I put it down for two weeks because I had to work on something

else and then couldn't remember how

to navigate the menu of my own game.

So, luckily a friend of mine has a brother who is blind and he was nice

enough not only to show me what screen readers are

but also to be very blunt and say this is completely unusable.

So, screen readers, most of you I realize completely know what

this is, for the few that don't,

a screen reader is actually a very sophisticated type of

technology that knows what's on your screen and tries to read it to you.

So, sorry, it knows what a button is, it knows what a slider is,

a drop-down box and it knows where on the screen it is,

so it can not only read it to you but can read to

you in order where it would appear on screen, so it actually makes sense.

I have a little audio sample for you, which is a screen reader

reading the main menu of the game, it's very short.

>> Main Menu.

"Play" button.

"Settings" button.

"Quit" button.

>> That's how it works and the fantastic thing about screen readers

is, (a) they exist on practically every platform,

Linux, Windows, Mac, iOS has VoiceOver, Android has TalkBack

and well now there's actually narrow it out on Xbox too.

But what's even better is they all pretty much work the same way

which means they set the interface conventions, which you should absolutely follow because

then, I saw this pretty quickly,

well every blind player could just pick up my game and immediately know how to use

it and even better they could come back after two weeks and still know how

to use.

There's really just two conventions to follow, one is all menu elements,

everything that's on stream should be accessible by swiping or if you're on

a PC it would be "arrow" keys if you're using a gamepad it would be the thumb stick.

But essentially, they all need to be accessible.

There shouldn't be any hidden commands you need to

do to get to that "Settings" button in the corner.

The second one is, you can activate one element with a double-tap.

That's on mobile obviously but it would be the "Return" key on the keyboard,

it would be probably the "A" key on the gamepad.

And it's always the same buttons or whether it's a slider,

a drop down or a button.

That's very important.

And once I came to my senses, I realized I really should follow these conventions

because navigating my games menu should not be my game's biggest challenge.

So I threw out all of my code, and redid it.

And go.

And the bare minimum you have to do to make your app accessible.

So bare minimum I started out with is marking up your UI.

You have to do some additional markup.

This, well, the actual bare minimum is choose a tech.

You either do a self voicing act, you write something that's natively

compatible with screen readers or use an engine or a third party plugin

and if you use Unity you're welcome to use my plugin.

So, the first thing, why do you need to do markup actually?

It's that, screen readers don't do everything for you because

games often use icons instead of text or a lot of graphics.

The classical ones are here, you have your triangle for "Play",

you have a check mark for "Okay", the red X for "Cancel".

The more I work with converting games I actually realize there's

a dozen more I could name without even breaking a sweat,

there's just so many that we've gotten used to and not very commonly used.

And this is great.

It makes a lot of sense to use images because well,

they use less screen space, this is especially valuable on mobile.

They oh yes, also screen space, they use always the same screen space

whereas if you translate texts even the word play,

it can be significantly longer in other languages.

If you design your UI and you don't know how long a Test is going

to be, it's accessible.

Also, you make your game accessible to people who can't read yet or

can't read English and last but not least you

have to save money on localization by using icon.

So, it's basically a win-win, win, win, win for the game developers.

The only thing is, it makes your game a little less accessible

because obviously screen readers can only read text.

So I recently converted a game to a, I think it was a trivia game,

to be accessible and here's an audio recording of what the screen reader

reads.

Just the text that's actually on the screen.

I'm not going to show you an image just yet.

>> Seven, 315, 97.

>> And that's it, just those three numbers.

I'm going to show you an image now and it's going to make sense.

Now, all of a sudden you see the seven in front of the heart meaning lives,

you see the 315 is actually a timer right next to

it and the 97 is right next to the stack of coins.

So, it makes a lot of sense.

Now, so, by just making your game screen reader compatible,

you just not done yet the game's not playable yet.

You could do a little bit of manual markup.

Now the actual tech that you need to do to do that,

differs on your platform, iOS and I think even yes,

Android too they have accessibility markup hence we could write

names into it.

So, this talk is applicable to whatever tech you're using,

I'm going to be using Unity examples just because I happen to work in Unity.

In Unity you add a component to it where you say this is my label,

it says five lives in this case and you just do a fill in the blanks sort of thing

where you say, "You have blank lives" and then at run time,

it replaces the blank with what's actually in

the label so you end up with you have five lives.

Now here is the same screen again after I did all that markup.

Just again, note just audio.

>> You have seven lives.

Time to next live, three minutes and 15 seconds.

You have 97 coins.

>> All of a sudden it makes sense.

And that's the bare minimum you have to do.

And that's the bare minimum I did and then I still didn't really have

a really great playable game because that's the point where actually went onto

a forum for blind players and put the game out there and ask for feedback.

But the thing is, I actually had no, knew, I thought I was done.

The game is accessible, it's playable, didn't expect too much and well that thread

grew to 18 pages worth of feedback really fast.

Most of it was really positive.

I also want to say there is, I have never gotten as much positive feedback from any

player, as I've gotten from blind players,

especially if you're even remotely familiar with

the Google Play Store review section and the comments.

There is a lot of vitriol there.

So, through all of these 18 pages of comments and

the tons of email I got and all the other forums,

I sort of picked my top five mistakes and top five lessons learned and how to avoid

them.

I'm going to present them here.

So number one.

Actually you know what, I should have called this,

"Avoid these five mistakes!"

Anyway, so, number one, don't write novels.

So basically I just said you have to write extra markup and that's fine

and I did that too but keep your inner author in check.

So navigating menu is functional, it's not artistic.

You have a goal in mind, you want to get somewhere.

You don't want to let your inner author get carried away here.

So this is what I did, I wrote long complete sentences into

all of my accessibility labels, I wrote, you currently have or your player

currently has this many items left in storage.

You'll see in a second why this is actually really annoying.

So, in the game crafting kingdom that we did you can craft items,

you can put them in your storage and then you can listen to what you currently

have in storage and this is what it sounded like when I did the first pass on

this.

>> You have 15 alarms in storage, you have 210 brooms storage,

you have 65 stone in storage, you have 123 iron ore in storage,

you have 16 gold bars in storage.

I'll spare you the rest there were 32 products.

So, well, luckily my players know exactly how to fix this,

so I immediately got the email, so I'll just make it shorter and just need

this.

So, in a nutshell, keep it short and put in

more information at the front.

So, bad.

Bad example, you currently have 15 moves left.

It turns out nobody actually listened to my long beautiful sentences,

they all just waited until they got the information that they needed and moved

on.

So, don't make them wait to you currently have just this is the better version just

15 moves left.

15 is information everybody wants if you come back to this label.

Fifteen, you can move on.

You don't even have to wait for the moves left,

but if you're a first-time player you realize, this is my moves label,

and tell me how many moves I have left.

So obviously, apparently, the number is going to go down.

So this is the actual audio that we ship with for the storage.

>> Moves 15, Timber, 200.

Stone, 65.

Iron ore, 123.

Gold bars,16.

>> So very short, not pretty but very functional,

and it made everybody happy.

So, this is my tip, keep it short put important information to

the front.

Number two, group your user interface.

This is a lot more complicated to explain I think.

So, I want to show you this video off the options menu of Crafting Kingdom,

which is this one.

See if it actually plays.

It does but only on my screen.

How do I get it?

Yes.

Okay.

This is the options menu.

Standard options menu.

You have your languages all on top, you notification, sound, music settings, cloud loading, that

kind of stuff.

Now, if I want to close this one, at the side of player,

I hit the "close button" at the bottom.

Here's what a blind player will have to do.

>> Language; English, German, French, Spanish, Japanese, Korean, Portuguese,

Russian, Italian, Vietnamese, Thai, Chinese notification sound effects, chips

music, chips accessibility enable excessive load

from Cloud.

Save to cloud ID, back button, let's return to select.

>> You get the idea I hope.

Yes.

So, if you didn't count that was 21 swipes

that you have to go through just to close a menu,

that you might have opened by accident.

Obviously you don't want that.

What we did in the end, I have another video.

So what you can do, and again this is doesn't matter what technique you use

it's just has different naming, you can actually group your UI.

Which means you can take a bunch of buttons and labels and

sliders and say they belong to one section or one group,

and then there's special gestures or keys we can jump from one group to the next

directly without having to go through every single UI elements on screen,

just takes a whole lot of time.

Navigating a UI is about as exciting as putting on a pair of socks if

you ask me, so it should be fast.

So what I did is I grouped all the languages together,

I grouped the sounds settings together, accessibility and Cloud Save and then it looks

like this.

We lost sound apparently.

We lost sound but essentially it was now five swipes to get to that one,

because you can jump between the individual ones really quickly.

So, yeah.

In a nutshell, cited players can skip over everything on

the UI that they don't need right now or don't want,

and you can give your blind players the same option.

So, my second tip or lesson learned his group UUI.

I'm already 60 minutes, [inaudible].

All right.

Number three, this one requires a little extra work,

so will the next one.

Anyway, to add additional audio, the thing is aside a player can obviously

take in entire screen at once and more

importantly you can grab his attention.

Everybody knows that if you make something flash or you make it animated up and down,

be given a bright red color, people will notice it, because

the human eye is attracted to movement.

No, I should have known this, it doesn't work for wind players obviously.

You nevertheless, we actually didn't consider this, for grafting kingdom,

you could craft a way happily and all your buildings would produce these products,

but then you storage would run fall.

And you'd never know that happened while as the site of player Yes it

did because the number in the corner of

your screen would turn bright red and it will start flashing

and growing bigger and smaller, but there was no sound attached to it at all.

Nothing no announcement, and obviously you started getting feedback.

Hey, I never know my storage is full.

I can swipe through the entire screen and listen to how much storage I have,

but I don't know if this happens while I'm somewhere in

a different screen and resetting my productions.

So, we added in spoken announcements.

Spoken announcements are useful for any type of notifications.

Basically, anytime you want to have the grafted player's attention

with any kind of pop-ups, maybe make a spoken announcement instead.

And all tech supports this I know that there's ways you can make an accessibility

announcement, you can have your own text

to speech implementation obviously, a plugin also supports

a just a simple say function that you can add additional stuff off.

A couple of examples, for example, you have mission complete.

If you have all your goals complete and can maybe finish the level,

storages fall which is from our game.

Your timer ran out and maybe you turned got skip which

actually was one in a board game that I just recently did,

or a chat message received.

You can also replace these with sound effects, because spoken announcement aren't always

fun, they interrupt the game play there somebody

constantly jabbering in your ear also not great,

and you might be listening on it's actually the same gesture that's awesome.

You might be listening to something else on your phone right now another announcement

you don't want an overlay.

In the case of Crafting Kingdom we had announcement that would tell

you how much productivity left in storage once you sold some of it.

But I got lots of feedback where people said, "I don't care,

I just want to move on and it wasn't skippable," they couldn't move

to the next product and sell it.

So, we started replacing some of these spoken text with sound effects.

And there's some that are obvious and easy to replace where you think,

that's easy nobody will misunderstand the sound of a rolling dye shore,

or what I owe.

Another example we did is, in the board game that we did when you rolled,

something and you couldn't do move.

We had an announcement first anyway it said, "Oh, no moves possible."

But instead replace it with just a buzzing sound,

and everybody got that, it was a negative sound,

and it would move on, but it's not always that obvious that you

can replace even more complex information with

the sound.

In the case of Crafting Kingdom, sorry, we had a world map where there

were are couple of hidden treasure chests.

And these treasure chests will just pop up on the screen and

if the player was on that part of the map at the time could see it,

you click it and get a couple of coins.

That would make impractically invisible to blind players,

because while there were accessible no one really always went through

the entire screen and checked every UI element just to see if

maybe something else popped up, and then some people found

them just by accident and said, "Oh, I didn't realize those were there because

you're not maybe at the sound."

So, we added a sound, a little jingling.

I'll play it.

It doesn't work.

Just imagine centers bells like [inaudible].

That's what I hoped would just instilled a image of getting a gift player.

So, we added that in and I forgot to add in anything into

the instructions or the sound actually means.

So we released the next version the sound was in,

and I thought no one would understand it.

Turns out everybody got it, because everybody just heard

the sound and maybe starting just searching, does this mean something?

They've found the treasure chest and then from

that moment on obviously they knew what it meant.

So, there's a couple of these and because I'm running short on time,

I'm not going to go through all of them but, you can replace way

more information with sound effects than you might think,

and maybe it's a good idea to forgo the actual spoken announcements every once

in awhile.

Number four, just two more to go.

Number four is even more complicated to implement on

your site than the last one.

Which is support multi-finger gestures.

My examples will usually be about mobile games but they're also

applicable if you make a PC game or an Xbox game.

So, multi-finger gesture.

So the thing is, you don't just use one finger while the sighted person on your

phone screen, your screen actually supports multiple fingers

and the screen readers that are there often use

this.

There's lots of two and three finger and now even four finger gestures.

Just get the latest iOS version, and there's two finger double-tap,

and three-finger triple taps and two-.