FCC / CVAA discussion

If it requires only "label/role/state/announcements" of things that are "standard across industries" then why is early design consideration a big deal?

 

Honestly it feels like you're trying very hard to twist things. I did not say that. I said that that set of label/state/role/announcements itself is what's standard.

Those also only cover one aspect of CVAA, as you know we were currently talking about text to speech and CVAA has many other requirements.

CVAA requirements in general must by law be required from early in the design process, because like anything in development it is harder to do a good job late in the day.

Even if you have a nice engine level system that just requires you to put in a few bits of metadata you can still get it wrong. Having worked in web accessibility for years too I've seen that plenty enough, the disastrous impact of making the wrong decisions and then not finding out until you're about to go live when you're in the middle of frantic bug fixing, or after launch when you've already scaled back your dev team. Even if the fixes are simple and easy, applying them at the end of dev may not be simple and easy at all.

Or the other requirement needed in order to meet CVAA's blind accessible criteria; digital UI navigation. Considering that from the outset VS trying to unpick and retrofit at the end can mean a really significant difference in cost, in effort, and in how effective the solution can be. I've seen that first hand, been dropped in to try to rescue a game that was in a pretty dire situation due to ignoring a publisher cert retirement to have keyboard accessible UI until the last minute... What would have been days' work if considered early ended up pushing launch out by months, and even after all of that wasn't very good.

The same principle applies to CVAA's other requirements too. Building controls that are flexible by default instead of having to go back and hack existing ones to be flexible. Knowing upfront to design messaging in a way that didn't depend on colour, and to avoid evenly spaced full caps for seizure risk, making both considerations zero cost. Etc etc.

I've been working in accessibility for over 11 years across games, web, apps, and cartography. And the one single common theme across all industries is to always consider it early. It isn't just said randomly for no reason, it's because it makes a huge impact. Instead of assuming I'm lying or something you could just type "consider accessibility early" into Google and see how much comes up.

If you won't take it from me, here are a few pertinent quotes from other people:

“I think the biggest thing right now that’s missing for most dev teams as far as, implementing this stuff, actually putting it into their games, is understanding when in the pipeline they need to start doing it. Which is very, very early on.”
- Alex Neonakis, Naughty Dog

"Integrated Accessibility is a state of mind, bolt on accessibility is a state of panic."
- David MacDonald, CanAdapt

"It’s a mindset, not a feature. It really should be considered in every step of the process."
- Karen Stevens, Electronic Arts

"The cost of retrofitting for colorblindness was huge, not thinking about it early quadrupled the work"
- Tara Voelker, Turtle Rock

That last quote is from a whole conference talk solely on the difference between considering accessibility early and late -

 

I think the misunderstanding between us is that I'm talking about more than just the CVAA, where you're only talking about (part of?) that.

My last few posts all arose from the example of a whole game being blind accessible. That's why I don't think it's reasonable to expect engines to offer similar levels of built-in support to platform-specific GUI frameworks.

 

I'll try explaining again:

The process of making UI blind accessible should be easy.

Outside of engines, creating blind accessible UI is straightforward enough that even an entire game can sometimes be made blind accessible by accident. This happens in two circumstances; 1. The gameplay is UI-based (like Football Manager or Hearthstone) or 2. The game has otherwise already blind accessible gameplay (like Killer Instinct or Forza).

Those four games are not currently fully blind accessible. However if UI accessibility had have been supported out of the box at engine level (and Football Manager and Hearthstone are both Unity games), they would be; at least to the extent that any work needed would be minor tweaks to metadata, not building an accessible UI framework from scratch.

Some games already being accessible purely by accident is simply an example of how easy it could and should be to make UI accessible.

The point is not that it should be easy to make the gameplay of all games blind accessible. What we are talking about engines supporting as well as native apps is not a "make the game accessible" button, native apps don't have that wither. The point is addressing the current vast discrepancy in work needed to make UI accessible.

Does that make more sense now?

 

I'll go with that.

I've only played a little Hearthstone, so I can't claim intimate familiarity, but do you really think all the cards and such would be covered by built-in engine support? They're exactly the kind of thing I'd expect to be bespoke. I certainly would not expect those to be created using off-the-shelf UI components, aside from probably some low level stuff like text rendering.

 

Just look at how it already works outside of engines, if you're building something like a website or a native app.

The component might be bespoke, but that doesn't mean that the approach is. If you're using an off the shelf UI component, the only thing you need to add is the label, because the role and state are already exposed. If you're using a bespoke component, you need to add that extra metadata in yourself.

So to compare similar things; if you're using an off the shelf checkbox component, you just included it and add a label. If you're making your own bespoke UI element that works in a similar way, you add the label, and add that it is a checkbox, and add whether it is checked or not.

Adding extra metadata is a very different thing indeed to implementing an entirely bespoke approach to blind accessibility, messing around with focus management and APIs and so on. .

As far as making a card game work, it might make more sense if looking at a real world example. Download a free xbox game called sa11ytaire, then go into the 'ease of access' system settings on the xbox and turn on narrator, and then play sa11ytaire with it turned on. Sa11ytaire is a card game with its UI exposed to the system level screenreader, so it's a decent demo of how Hearthstone could work if Unity supported this kind of stuff.

You could just watch a video actually:

You can easily see from that how the metadata that the screenreader is pulling out breaks down. A label of 'remaining card pile next card', a role of 'button'. A label of "card pile 1, ace of clubs, 1 of 1", a state of "unselected". An announcement to say that moving the card has resulted in card pile 1 being empty.

That's what I mean about standardised. Regardless of what kind UI you're building, it really does break down into name/role/state and announcements. I've worked with plenty of designers who think they're inventing new paradigms, but they really are not

Does that all make more sense now? Hopefully you can see that getting a UI working with screenreader software like that through flagging things up in the right way is really trivial when compared to the effort of rolling your own entirely bespoke solution for how to approach blind accessibility. But currently in Unity your option is the latter, or paying for a plugin that replicates the external functionality inside Unity.

 

@ianhamilton_ said (s)he's a designer for long time. Does that even compare to a developer? I mean from a technical stand point?

Any advocate for something this complicated should be highly knowledgeable!

 

Do you really think that building Hearthstone is comparable to creating a website? (The term "native app" is not very useful here.)

Even this may would have required some bespoke implementation. "Card pile 1, ace of clubs, 1 of 1" is a bunch of game state being read from the game model and presented ("rendered") as a text string. Specific to the "1 of 1", do you happen to know if that's a built-in recognition and representation of collections? (Edit: Changed "probably" to "may", as I can certainly imagine GUI framework designs that could cover this.)

Consider, since I've been talking about making a whole game accessible, how much that complexity would blow out when it comes to any game with a virtual environment. I certainly think it's possible because, as you said, it's essentially just a different type of rendering. That said, there's a heck of a lot of contextual information required there that simply doesn't apply to most things done in a traditional GUI framework, eg: how far away is the thing I am looking at, and does that change how it should be presented?

Which comes back to my original point. Even if "Unity supported this kind of stuff" making a whole game accessible is still a non-trivial task.

For clarity, I am not arguing that we shouldn't make things accessible! Just that it's not as straightforward as non-technical people seem to think.

 

@ianhamilton_ I realize you're just trying to inform and have no power as far as changing the regulation. I get that it's a done deal.

In your work have you come across any solo developer or tiny (2 to 3 people) game development team who have made their games compliant?

I'm just wondering if you have worked with or know of any developers outside of AAA teams and large Indie teams who have done this and could give some examples. It might be very helpful if some guidance can be provided to devs from the perspective of a solo developer or 2 to 3 person team who has done it.

 

That's for AAA only. Did you know that the majority of games, the vast, vast majority of games on the entire planet are done by tiny teams and single indies?

Not one single quote applies to indies. Not one. Why? because AAA is the tiniest minority in the market when it comes to developers. There are millions of indies and more arrive every single day. Cast a stone on these forums and it'll hit some dude slaving away on his pixel art game. Hundreds of games come out every single month. That's the sheer amount of illegal content nobody can be bothered to complain about or even realise they can.

If it's law, it kinda sucks and is impotent, and nothing you can do will change that. You can't tax that creative freedom and nor should you.

The length of time and resources required to implement all this for an indie is basically the same as making the whole game. Plus an indie isn't able to plot exactly what the game even is, let alone design for it in the early stage. When you are naughty dog with a billion dollar parent and unlimited staff it's OK.

But for the majority of game developers...

There's no staff you see. It's just one person. Maybe two, and you've basically nuked every small piece of joy those people would have because they have to do nothing but accessibility for someone who will likely never, ever find their game.

It's time to accept that indie works are entirely exempt. Just ignore all companies under 1m bucks, which so happens to be the cap you can fine people for.

 

The CVAA shouldn't have this impact, because it's only for the communications systems within a game.

I agree it'd be neat if the word "reasonable" ended up having this effect for the harder-to-do stuff.

Things like making sure our colour theory is broadly accessible and stuff like that... well, I'd hope people do that anyway?

 

Especially interfaces in VR. Where it then becomes a NUI.

FCC has just ruined the future for NUI's by imposing rules that prohibit experimentation with new ideas, unless they satisfy some unknown ruleset.

FCC, obviously has head up own ass.

Agreed!!

I smell class action lawsuite brewing somewhere.

 

Luckily you're wrong. I'm sorry dude but my time is up for you, I've spent many many hours now trying to explain this, time that's at the cost of not doing paid work, so I hope you can understand that I need to draw a line at some point.

For more info I'd recommend looking into the implementations for Diceworld, MUDrammer, Solara, Skullgirls, Crafting Kingdom and Eagle Island, I'm sure the devs of any of those would be up for a chat.

Here's one example, replace the talk of the plugin with imagining the engine did the plugin work instead, as the the end result for devs is the same with the plugin as it would be for engine level support. She went way above and beyond the basics of making it accessible, and even with all the extra QOL work for optimising blind gamers' experiences it took her 4 days.

https://icodelikeagirl.com/2017/03/...fast-can-you-make-an-existing-app-accessible/

 

@ianhamilton_ what I think would really help things along would be for you to create a Unity Project that implemented multiplayer chat functionality in compliance to the CVAA. No bells, whistles or fancy stuff, just a functioning project with a chat system that people can open up and sift through to better understand what's required and perhaps resolve some ambiguities.

If this law is sufficiently clear to be useful, and not going to add a ton of work for developers, it shouldn't take very long to spec this project and create it.

 

I am not a Unity developer. But I have no doubt that someone will do that. Probably financially motivated. I'd hope that Unity themselves would step up and do it themselves.

 

You just called him "Dude". Are you an adolescent??

I know a place where you can draw that line:

------------------------> [EXIT]

 

Cool. About which bit?

I already corrected the bit where I said those labels would require bespoke work, so I assume you mean something else?

 

Perhaps if you have some Unity developer friends in the same position as you (spending a significant amount of time and effort advocating for accessibility) you might suggest this as a way to demonstrate by example rather than words.

Things tend to look quite easy on pen and paper, but implementing even a very isolated test case like this will likely show a lot of unexpected difficulties and require an unexpected amount of clarification.

 

I'm very much aware of data on studio size.

There's a very simple reason why I chose those quotes; because they're from reknowned developers, people who I obviously incorrectly assumed it would be easy to take the word of.

If it would be easier to take the word of some micro-indies on how accessibility should be considered early, here are a few -

"Inclusivity and accessibility remain topics that your game can probably do better at minimal effort, if you just give it early thought."
- Rami Ismail, Vlambeer

"Rewire your brain when thinking of "everyone". Build your game with accessibility in mind early on. Why exclude when you can be inclusive"
- Fakhra AlMansouri, HybridHumans

"Quite seriously, accessibility and inclusion are the biggest gains to your potential userbase, and by doing it as early as possible, you're giving your game the best chance of success."
- John Kane, Gritfish

"I’m trying to present my ideas to encourage devs to consider vision impairment accessibility very early in the game dev process."
- Brian, DaisyAleSoundworks

In October there was this lovely talk solely on the topic of the difference considering makes to a one-man indie, using his last two games as a comparison -

https://mobile.twitter.com/GA_Conf/status/1047466123325853698

The amount of resources required will NEVER be anywhere close to the resources needed to make the whole game. The law requires doing as much as is reasonably possible.

As angrypenguin rightly says some things will always be reasonably possible, like ensuring text chat works for people who are colourblind. Other things might be too difficult and expensive. If they are, you don't have to implement them, that's literally how it works.

There was a blanket exemption in place for small companies. It was a temporary exemption though, an extra year's heads up, it ran out in 2013. Finished.

Personally I would rather have seen a permanent blanket exemption for small companies, but that isn't how it works, and no amount of wishful thinking or strongly held opinions will change that.

 

Thanks, I appreciate that!

I don't know any companies of any scale who are compliant, I only know if people working on compliance for games that haven't been released yet (or announced yet).

It's going to be messy, at least for the first six months or so, it'll take a little time for examples to surface but when they do yes absolutely, they'll make everyone's lives easier.

 

Your statement means nothing until you define: reasonable

Please stop trying to persuade without providing any real context.

 

And costly. And required all projects regardless of size, intention, audience, skill level or development stage to conform...

You say it as if examples are going to give back the time lost learning/adding/maintaining all of them.

---

I think it is ironic how CVAA may be the death of in-game comms, so less games will have communications in general. Was that the intention, or did I miss something??

 

Yikes! all in 2018:

• Fifty colleges sued in barrage of ADA lawsuits over web accessibility
• ADA website lawsuits a growing problem for retailers
  
• Lawsuits targeting business websites over ADA violations are on the rise
• Trump hotel in Chicago sued for alleged ADA violations
• UPMC becomes latest target of disability-rights activist suing

CVAA can also be weaponized!

 

Maybe they should follow the F***ing ADA then. It's literally been a thing for over 30 goddamn years.

 

Interesting how similar their perspective is to some of the stuff people are talking about here:

My bold:

 

So, if a student builds a web app for a teacher while in class, and that app becomes helpful for a network of other students? then that academic institution can automatically be sued due to non compliance.

Do you truly believe that's healthy?

 

These are recruiting websites and online retailers, not student projects. If it's going to be used on a wide scale like that then, yes, it should be compliant. This is not difficult to understand nor unreasonable.

 

So basically AAA

 

That is not even remotely what I said.

 

Sorry, could you clarify then?

 

If you want to use something in a professional capacity and there is a chance that disabled people will be using it, like on a college recruitment site (because the disabled go to college) and online stores (because disabled people buy things), you are subject to the ADA. If you make a website that is incompatible with a screen reader, for instance, you have no excuse.

 

If you have a big house and you decide to throw a party where anyone and everyone is welcome to join you (let's say for $5 to cover the drinks) imagine being sued for not having wheelchair ramps and such?

Because that's essentially the equivalent of what an indie game is. It's the bottom end of 'commerce', a free-wheeling marketplace that runs more on fun and inspiration than specific services and standards. That sort of thing should not be interfered with.

I understand that many people here (including @ianhamilton_) agree on the idea of a permanent blanket exemption for small companies. Well the question is, who didn't agree? Every single substantial video I can find on the subject has comments disabled, presumably because many people don't like it. Is it the FCC themselves then? If they decided to take matters into their own hands that's even worse news.

 

Good sway,

My rebuttal:

But why should an indi game be required to the same high standard as a AAA?

While (in your view) a student's social networking webapp is not comparable to administrative and/or eCommerce webapps?

Double standard..

---

I would like my game to be reachable by everyone, but sales need to come first and bugs worked out before I can spend any time on that stuff. I don't even know which game will jive in public's eyes until field test and betas are released.

Getting sued during a beta release would be humiliating...

So you may be surrounded by a team that has lots of funds to not worry about it, but I make prototype games, which means I am way more at risk because I merely test concepts, I'm sure your creations are a bit more matured..??

 

Yeah, but only if it was reasonably easy to add the ramps (say, you could add them by spending an extra 2% of the time it took you to plan the party)

 

Except that proving that it would not have taken you 2% of the time to plan the party might take 100% of the time it took to plan the party, and cost 10000% of the cost of throwing the party.

 

Yeah? What’s your point here? Lawsuits take time?

 

Yes, that's right.

 

That has absolutely nothing to do with this law though.

 

My point is that there is a certain level in society where the mere presence of bureaucracy and regulation is troublesome and ineffective. Where the mere threat of a lawsuit is enough to destroy the momentum and the joy of something. Where the aims are not always clear (and that's ok), the inspiration and motivation comes and goes, and where there are certainly no 'public services' being provided.

 

A very relevant summary.

 

I don't disagree, but I just don't think this law is the best representation of that, which is why I think this whole argument has little to do with this thread.

Frivolous lawsuits can happen for much sillier reasons especially once you release a game (or anything) and bureaucracy is already insane.

At least this law is for something I can get behind.

 

Valid point. And I would also stand behind accessibility (after my game has been established),

As Billy4184 correctly states, no 'public services' are being provided in games and the argument has long been they should demonstrate positive re-enforcement instead of exerting punishment and time delays.

This should not even be law, and rather a set of recommendation, incentivized by tax exemptions for those who follow them.

 

Hypothetical question:

Imagine you are being sued because one of your low priority games is unacceptable to someone and they demand better chat font or silly icons.

In response I patch an update where I remove the chat functionality completely from that game.

Is the claim resolved and dropped immediately?

If yes, then right after it has been dropped, patch another update and fire back up the chat functionality.

Get sued again, and just patch another update that removes it again, and again, if necessary.

If no, then the FCC is suing a game that has no advanced communications, which would be illegal.

 

If it's a low priority game, then you haven't done a major update to it in a while, so it's already exempt from the CVAA (until you do a major update)

 

Assume it is a newly released prototype concept game or tool.

 

I would say that at its core, it's on the line between being rational or not. If the rules were very clear, the solutions standardized, and the penalties reasonable, I could say "fair enough, why not". But it's as clear as mud, you're expected to essentially deal with the US government directly - outside the legal system - you're guilty until proven innocent and there's a $1m fine hanging over your head. That's way too far. An established business might be able to deal with that, but not an indie.

Another good reason not to make it worse.

I'm pretty much behind some regulation for AAA and maybe AA (depending on one's definition). Because they have enough of an audience that the impact of accessibility will be significant. For an indie though it's the straw (or maybe the log) that broke the camel's back. And above all, it means risk. Indies don't need more risk.

My main issue is clarity. The law is not clear. Surely it cannot be too much to ask to see a compliant project with nothing more than a chat system in it (since that's supposed to be the only thing affected..?), but I fear even this causes undue pressure on the law to resolve itself into something substantial.

 

For each offense!

 

Correct

 

Since @ianhamilton_ has me on ignore, (s)he obviously has no idea what we were just talking about.. LOL!

 

OOH OH
I have another one.
As done by master Gaijin.
Game in open beta forever. It's not technically released so it's exempt.

Also what does "major update" even mean? I can just claim that an update is not a major update?