Ignore that person, they are using accessibility as an excuse for the fact that they do not like a feature on the site, the odds of using that combination of keys when using a screen reader by mistake are about a thousand to one.
Especially as screen readers have modifier keys to ensure collisions are minimal.
Only thing I would say is make it clear that if you do activate the easter egg by mistake that you can exit with Esc plus have a button that you can focus and click to exit. Also make sure focus is returned to the last place in the document when it is closed.
The last part is just a final bit of making it bullet proof in case someone does happen to accidentally hit that key combination.
Obviously if the key combination is much shorter (or interferes with normal keyboard operation by using e.preventDefault()) then that is a different story.
Edit
As for some reason this got the one downvote (despite being written by someone who uses a screen reader every day for work and works heavily in accessibility) I am guessing I better elaborate on why the Konami code is not a problem.
For clarity this advice is specifically for the Konami code activating an Easter egg, not a comment on Easter eggs themselves or shorter key sequences (which I already said).
Up, Up, Down, Down, Left, Right, Left, Right would be an "interesting" key sequence to use in a screen reader to say the least.
You would essentially be doing:-
- previous item
- previous item
- next item
- next item
- previous character / cell / item in list
- next character / cell / item in list
- previous character / cell / item in list
- next character / cell / item in list
- NVDA - Jump to the next button (if in a form) / JAWS - Jump to the next button (if in a form) / VoiceOver - pretty sure does nothing without modifier key
- NVDA - invalid command / JAWS - next radio button if in form else nothing / VoiceOver - nothing (unless holding modifier key)
Now we could argue that someone might bind their keys differently but even then, the odds of that sequence of keys being used accidentally is ridiculously low due to the repetition of conflicting commands (the first 8 keys would essentially mean you ended up where you started, or if you rebound them to different keys end up repeating very strange commands).
And as I said, if magically someone does do some strange operation (maybe they are checking a complex form and want to check the same field 4 times and then jump to a button which is magically activated when you type the letter "A" and then "Enter" 🤣?) then as long as there is a way to easily exit the game then this is not an accessibility issue.
And believe me, if the Konami code is the worst accessibility issue you have on your entire site, you have the best website in the world and no disabled user will begrudge you having a little bit of fun once a year if for 95%+ days of the year your site is perfectly accessible!
SO back to my original conclusion - from an accessibility perspective this is not an issue and anyone telling you it is just wants to suck the fun out of things because "it is not professional" or some other reason, which is an entirely different thing to accessible. /end rant 😁
Any relevant WCAG guidance?
Yes, we have SC 2.1.4 Character Key Shortcuts. You are fine here as this is not a single character shortcut key
SC 2.1.2 Keyboard Trap - you are fine here if you implement the Esc key to close and or a <button> to close the game as discussed.
SC 2.2.2 Pause, stop, hide - you pass if you can hide the animation (the game), but as an added extra step if the game automatically starts with an animation you may want a different loading / home screen that is static using the prefers-reduced-motion media query.
SC 3.2.2 On Input and SC 3.2.5 Change on request do not apply here due to how the game is activated, however they are probably a good indication of the potential issues of unexpected behaviour.
Yet again if the key sequence was more typical and shorter I would cite this as a concern, but due to the chance of accidental navigation being negligible I would not worry.
This perhaps is the closest you will get to an actual argument against the Konami code though. Ironically I would argue that if someone enters that key sequence they are hoping to find an Easter egg so it would be expected behaviour!
All other WCAG - You obviously need to ensure that the game itself is accessible, but that would require me to list nearly every other criteria and isn't related to the Konami code, so I will just mention it here as something you need to consider.
Is there anything else I could do to improve accessibility while keeping this feature?
Yes!
First when the Konami code is entered have a modal appear that explains:
"you have entered the Konami code. The Konami code is (key sequence) and (explanation of the history of the Konami code)."
Then have two buttons
"play our game as a bonus for finding the Konami code?"
or
"please disable the Konami code for me".
That way you give users the option to disable that key sequence, but you also explain why there was a popup in the first place.
Depending on the site, if there is a user settings screen, you could add the option to disable the Konami code there too (you do have an accessibility settings screen don't you? 😋).
Just a couple of suggestions that could make this even more accessible with very little effort.
