E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 7 (In chronological order)

From: jeffgutsell
Date: Wed, Aug 26 2020 12:45PM
Subject: Web-based games
No previous message | Next message →

The latest Syntax podcast includes a discussion of creating a minesweeper-style Web game with the React framework. The hosts suggested using React's pointer events. That made me cringe. I know little about React or its pointer events, but I assume that using them excludes keyboard users. Perhaps they will work on touch screens?
today I did some searching and found skimpy resources for a developer wanting to create an accessible Web game. Does anyone have suggestions for reading materials on this topic.
Jeff Gutsell

From: Nolan Darilek
Date: Wed, Aug 26 2020 1:12PM
Subject: Re: Web-based games
← Previous message | Next message →

I can speak a bit to this. I'm about to launch an audio game on a
variety of platforms. I do support the web, though I likely won't for
this title since my approach has some rough edges.


Broadly speaking, you have a couple approaches. First is to stick close
to HTML elements, using regular web accessibility practices to iron out
the rough edges. This can work for more UI-focused games, or for games
where performance and graphics needs aren't too heavy. You're also
pretty much tied to the web, which may or may not be a good thing for
your use case.


The second approach is rendering to a canvas. At this point you've
abandoned web accessibility, and are thoroughly in roll-your-own
territory. This isn't necessarily the bad thing it may sound like. What
do WCAG and the ARIA authoring guidelines recommend to, say, make
Asteroids or Pong accessible? :) Rolling your own lets you use the same
code on multiple platforms and, say, port an SDL game to WebAssembly.
You can often call out to JavaScript to, say, use the speechSynthesis
API. You can also use more traditional game engines like Unity, then
compile to a web target. You have lots of power, but also lots of
responsibility if you want accessibility.


Hybrid approaches are also possible, though I haven't delved as much
into these. You could use HTML for your UI, then unhide a canvas and
start a game loop when a Play link/button is clicked. This could also
work with wasm as well--make your game's `main()` function immediately
launch the game, and have your Play button call that.


For my part, I've written a cross-platform screen reader that runs in
the open source Godot engine. Currently supported platforms are Linux,
Windows (desktop and universal, possibly the Xbox), Android, MacOS, and
the web. iOS should be coming soon once I've figured out how to
successfully dance with Apple. This approach does put you pretty
squarely outside of web accessibility land, but I don't know if web
accessibility techniques are up to, say, conveying a world like The Last
of Us 2 as a game engine can be made to (but I'd certainly welcome being
wrong on that. :) I don't necessarily recommend my approach as
one-size-fits all, but I hope my ramblings help to put some perspective
on the landscape of accessible web games. I don't plan on releasing
future titles to the web right now, but they'd make great concept demos
for quickly trying out game mechanics without me having to build them
for each platform I support, and end users having to download and
install them.

On 8/26/20 1:45 PM, = EMAIL ADDRESS REMOVED = wrote:
> The latest Syntax podcast includes a discussion of creating a minesweeper-style Web game with the React framework. The hosts suggested using React's pointer events. That made me cringe. I know little about React or its pointer events, but I assume that using them excludes keyboard users. Perhaps they will work on touch screens?
> today I did some searching and found skimpy resources for a developer wanting to create an accessible Web game. Does anyone have suggestions for reading materials on this topic.
> Jeff Gutsell
>
>
> > > >

From: Patrick H. Lauke
Date: Wed, Aug 26 2020 1:23PM
Subject: Re: Web-based games
← Previous message | Next message →

On 26/08/2020 19:45, = EMAIL ADDRESS REMOVED = wrote:
> The latest Syntax podcast includes a discussion of creating a minesweeper-style Web game with the React framework. The hosts suggested using React's pointer events. That made me cringe. I know little about React or its pointer events, but I assume that using them excludes keyboard users. Perhaps they will work on touch screens?

Pointer Events (which, as far as I know, is what React uses natively,
with polyfills/fallbacks for older browsers that don't implement them)
are an event model that covers all possible pointer-type inputs (mouse,
stylus, touchscreen). Using pointer events makes sure that stuff works
on various desktop/mobile/tablet/hybrid devices and with various input
types.

And yes, pointer events on their own won't help/do anything for keyboard
users (and the PE spec warns about this directly - see the note in the
introduction https://w3c.github.io/pointerevents/#intro)

Full disclosure: I'm chair of the WG and co-editor of the spec ;)

> today I did some searching and found skimpy resources for a developer wanting to create an accessible Web game. Does anyone have suggestions for reading materials on this topic.

It depends heavily on the type of game. In general, action/realtime
games will be exceedingly hard to make fully accessible (including
screen reader/AT users), while turn-based simple games are much easier
to accommodate with mostly general web-development concepts like making
sure there are focusable/keyboard operable controls, that content is
semantically structured, etc.

There's of course also varying levels of "accessible". Just making a
game keyboard accessible is much easier than also conveying the current
state (e.g. the whole "mine field") to an AT user in a sensible way (a
giant table/grid for instance). And you may even end up making something
that is technically accessible to screen reader users, but so utterly
tedious to navigate and use, that you may as well not bother.

Sorry, no simple answer or pointer...just that, unless we're talking
really basic games, making even a moderately complex game fully
accessible can be extremely challenging.

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Lucy GRECO
Date: Wed, Aug 26 2020 2:17PM
Subject: Re: Web-based games
← Previous message | Next message →

HELLO:
I WOULD REACH OUT TO Ian Hamilton https://twitter.com/ianhamilton_
AS HE IS ONE OF THE TOP PEOPLE IN GAME ACCESSIBILITY.
I WOULD RECOMMEND STAYING AWAY FROM AUDIO ONLY GAMES IT DRIVES ME AND
OTHER BLIND PEOPLE CRAZY WHEN WE FIND A GOOD GAME THAT OUR SITED
FRIENDS WON'T PLAY.
i PLAY GAMES TO BE SOCIAL AND I DON'T ONLY WANT TO PLAY WITH OTHER BLIND
PEOPLE. SO MAKE SURE IT'S INCLUSIVE TO EVERYONE NOT JUST BLIND OR KEYBOARD
ONLY ETCETERA.

I DID FIND AN INTERESTING NEW PLATFORM A FEW WEEKS AGO THAT IS IN
PUBLIC ALPHA BUT I AM NOT GOING TO SHARE THE LINK HERE AS THE FILE I
DOWNLOADED TURNED OUT TO HAVE SOME PRETTY CRITICAL VIRUSES IN IT. AND THEY
DID BREAK THE RULE I HAVE OF NOT BEING AUDEO
ONLY.
SMILE EVEN A PRIMITIVE MAP IS BETTER THEN NO MAP AS FAR AS I AM CONCERNED
LUYC

Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces



On Wed, Aug 26, 2020 at 12:23 PM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 26/08/2020 19:45, = EMAIL ADDRESS REMOVED = wrote:
> > The latest Syntax podcast includes a discussion of creating a
> minesweeper-style Web game with the React framework. The hosts suggested
> using React's pointer events. That made me cringe. I know little about
> React or its pointer events, but I assume that using them excludes keyboard
> users. Perhaps they will work on touch screens?
>
> Pointer Events (which, as far as I know, is what React uses natively,
> with polyfills/fallbacks for older browsers that don't implement them)
> are an event model that covers all possible pointer-type inputs (mouse,
> stylus, touchscreen). Using pointer events makes sure that stuff works
> on various desktop/mobile/tablet/hybrid devices and with various input
> types.
>
> And yes, pointer events on their own won't help/do anything for keyboard
> users (and the PE spec warns about this directly - see the note in the
> introduction https://w3c.github.io/pointerevents/#intro)
>
> Full disclosure: I'm chair of the WG and co-editor of the spec ;)
>
> > today I did some searching and found skimpy resources for a developer
> wanting to create an accessible Web game. Does anyone have suggestions for
> reading materials on this topic.
>
> It depends heavily on the type of game. In general, action/realtime
> games will be exceedingly hard to make fully accessible (including
> screen reader/AT users), while turn-based simple games are much easier
> to accommodate with mostly general web-development concepts like making
> sure there are focusable/keyboard operable controls, that content is
> semantically structured, etc.
>
> There's of course also varying levels of "accessible". Just making a
> game keyboard accessible is much easier than also conveying the current
> state (e.g. the whole "mine field") to an AT user in a sensible way (a
> giant table/grid for instance). And you may even end up making something
> that is technically accessible to screen reader users, but so utterly
> tedious to navigate and use, that you may as well not bother.
>
> Sorry, no simple answer or pointer...just that, unless we're talking
> really basic games, making even a moderately complex game fully
> accessible can be extremely challenging.
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >

From: Nolan Darilek
Date: Wed, Aug 26 2020 2:25PM
Subject: Re: Web-based games
← Previous message | Next message →

I'd caution against dismissing audio games outright because that's all
some of us can do. I myself am blind. If I could create games with
graphics, or could actually afford to hire someone for the visuals, I
would. And, all things being equal, I'd prefer an accessible inclusive
game to an audio-only game. That said, I have bunches of game ideas
kicking around in my skull, some that I genuinely think push the state
of the art in game accessibility, and I'm not going to *not* do those
because all I can muster is audio. :)


That said, if you have the ability to do something that isn't
audio-only, please do. That's part of why I added accessibility to an
open source engine, because I'd actually like to collaborate alongside
sighted developers to build more inclusively.


Anyhow, I don't want to go too far off-topic for a web development list.
I just wanted to plug audio games a bit, even if I'm simultaneously
creating them while knowing they aren't our future.

On 8/26/20 3:17 PM, Lucy GRECO wrote:
> HELLO:
> I WOULD REACH OUT TO Ian Hamilton https://twitter.com/ianhamilton_
> AS HE IS ONE OF THE TOP PEOPLE IN GAME ACCESSIBILITY.
> I WOULD RECOMMEND STAYING AWAY FROM AUDIO ONLY GAMES IT DRIVES ME AND
> OTHER BLIND PEOPLE CRAZY WHEN WE FIND A GOOD GAME THAT OUR SITED
> FRIENDS WON'T PLAY.
> i PLAY GAMES TO BE SOCIAL AND I DON'T ONLY WANT TO PLAY WITH OTHER BLIND
> PEOPLE. SO MAKE SURE IT'S INCLUSIVE TO EVERYONE NOT JUST BLIND OR KEYBOARD
> ONLY ETCETERA.
>
> I DID FIND AN INTERESTING NEW PLATFORM A FEW WEEKS AGO THAT IS IN
> PUBLIC ALPHA BUT I AM NOT GOING TO SHARE THE LINK HERE AS THE FILE I
> DOWNLOADED TURNED OUT TO HAVE SOME PRETTY CRITICAL VIRUSES IN IT. AND THEY
> DID BREAK THE RULE I HAVE OF NOT BEING AUDEO
> ONLY.
> SMILE EVEN A PRIMITIVE MAP IS BETTER THEN NO MAP AS FAR AS I AM CONCERNED
> LUYC
>
> Lucia Greco
> Web Accessibility Evangelist
> IST - Architecture, Platforms, and Integration
> University of California, Berkeley
> (510) 289-6008 skype: lucia1-greco
> http://webaccess.berkeley.edu
> Follow me on twitter @accessaces
>
>
>
> On Wed, Aug 26, 2020 at 12:23 PM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> On 26/08/2020 19:45, = EMAIL ADDRESS REMOVED = wrote:
>>> The latest Syntax podcast includes a discussion of creating a
>> minesweeper-style Web game with the React framework. The hosts suggested
>> using React's pointer events. That made me cringe. I know little about
>> React or its pointer events, but I assume that using them excludes keyboard
>> users. Perhaps they will work on touch screens?
>>
>> Pointer Events (which, as far as I know, is what React uses natively,
>> with polyfills/fallbacks for older browsers that don't implement them)
>> are an event model that covers all possible pointer-type inputs (mouse,
>> stylus, touchscreen). Using pointer events makes sure that stuff works
>> on various desktop/mobile/tablet/hybrid devices and with various input
>> types.
>>
>> And yes, pointer events on their own won't help/do anything for keyboard
>> users (and the PE spec warns about this directly - see the note in the
>> introduction https://w3c.github.io/pointerevents/#intro)
>>
>> Full disclosure: I'm chair of the WG and co-editor of the spec ;)
>>
>>> today I did some searching and found skimpy resources for a developer
>> wanting to create an accessible Web game. Does anyone have suggestions for
>> reading materials on this topic.
>>
>> It depends heavily on the type of game. In general, action/realtime
>> games will be exceedingly hard to make fully accessible (including
>> screen reader/AT users), while turn-based simple games are much easier
>> to accommodate with mostly general web-development concepts like making
>> sure there are focusable/keyboard operable controls, that content is
>> semantically structured, etc.
>>
>> There's of course also varying levels of "accessible". Just making a
>> game keyboard accessible is much easier than also conveying the current
>> state (e.g. the whole "mine field") to an AT user in a sensible way (a
>> giant table/grid for instance). And you may even end up making something
>> that is technically accessible to screen reader users, but so utterly
>> tedious to navigate and use, that you may as well not bother.
>>
>> Sorry, no simple answer or pointer...just that, unless we're talking
>> really basic games, making even a moderately complex game fully
>> accessible can be extremely challenging.
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
>> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>> >> >> >> >>
> > > >

From: Brandon Keith Biggs
Date: Wed, Aug 26 2020 2:41PM
Subject: Re: Web-based games
← Previous message | Next message →

Yes, to second Nolan,
Games, for the most part, move out of semantic HTML.
For some strange reason, people like to do games in React, when React is
not a gaming framework. None of the games that are built with React,
without a screen reader user testing them, that I've seen, are accessible.
Even the React website's tutorial is not accessible (although there is an
open issue on Github).

This is an area of interfaces WCAG guidelines don't apply to, and semantic
HTML breaks down. Almost all games, except for HTML-based games, will only
have an application element, with possibly some menus, and maybe an element
with aria-live.
Thanks,

Brandon Keith Biggs <http://brandonkeithbiggs.com/>;


On Wed, Aug 26, 2020 at 12:12 PM Nolan Darilek < = EMAIL ADDRESS REMOVED = >
wrote:

> I can speak a bit to this. I'm about to launch an audio game on a
> variety of platforms. I do support the web, though I likely won't for
> this title since my approach has some rough edges.
>
>
> Broadly speaking, you have a couple approaches. First is to stick close
> to HTML elements, using regular web accessibility practices to iron out
> the rough edges. This can work for more UI-focused games, or for games
> where performance and graphics needs aren't too heavy. You're also
> pretty much tied to the web, which may or may not be a good thing for
> your use case.
>
>
> The second approach is rendering to a canvas. At this point you've
> abandoned web accessibility, and are thoroughly in roll-your-own
> territory. This isn't necessarily the bad thing it may sound like. What
> do WCAG and the ARIA authoring guidelines recommend to, say, make
> Asteroids or Pong accessible? :) Rolling your own lets you use the same
> code on multiple platforms and, say, port an SDL game to WebAssembly.
> You can often call out to JavaScript to, say, use the speechSynthesis
> API. You can also use more traditional game engines like Unity, then
> compile to a web target. You have lots of power, but also lots of
> responsibility if you want accessibility.
>
>
> Hybrid approaches are also possible, though I haven't delved as much
> into these. You could use HTML for your UI, then unhide a canvas and
> start a game loop when a Play link/button is clicked. This could also
> work with wasm as well--make your game's `main()` function immediately
> launch the game, and have your Play button call that.
>
>
> For my part, I've written a cross-platform screen reader that runs in
> the open source Godot engine. Currently supported platforms are Linux,
> Windows (desktop and universal, possibly the Xbox), Android, MacOS, and
> the web. iOS should be coming soon once I've figured out how to
> successfully dance with Apple. This approach does put you pretty
> squarely outside of web accessibility land, but I don't know if web
> accessibility techniques are up to, say, conveying a world like The Last
> of Us 2 as a game engine can be made to (but I'd certainly welcome being
> wrong on that. :) I don't necessarily recommend my approach as
> one-size-fits all, but I hope my ramblings help to put some perspective
> on the landscape of accessible web games. I don't plan on releasing
> future titles to the web right now, but they'd make great concept demos
> for quickly trying out game mechanics without me having to build them
> for each platform I support, and end users having to download and
> install them.
>
> On 8/26/20 1:45 PM, = EMAIL ADDRESS REMOVED = wrote:
> > The latest Syntax podcast includes a discussion of creating a
> minesweeper-style Web game with the React framework. The hosts suggested
> using React's pointer events. That made me cringe. I know little about
> React or its pointer events, but I assume that using them excludes keyboard
> users. Perhaps they will work on touch screens?
> > today I did some searching and found skimpy resources for a developer
> wanting to create an accessible Web game. Does anyone have suggestions for
> reading materials on this topic.
> > Jeff Gutsell
> >
> >
> > > > > > > > > > > > >

From: jeffgutsell
Date: Thu, Aug 27 2020 10:15AM
Subject: Re: Web-based games
← Previous message | No next message

Everyone,
Thanks for the great responses.
Some background: I focused on the podcast discussion because this came just
a few days after a friend asked me to create a coin flip game for him. I am
retired and generally don't take on work for others. However, he mentioned
wanting the game to be accessible -- without prompting from me. So I decided
to think about it. There could not possibly be a simpler game than this. I
will try to jazz it up with some animation and audio. Of course it will
need a live region.
I may go out of town for a short trip soon, so I am not sure when I will get
this done.

Jeff