code: function( event ) {
  
              // Don't trigger navigation for example when user returns to browser window with ALT+TAB
              if ( event.altKey || event.ctrlKey || event.metaKey ) {
                  return false;
              }
  
              // In the case of TAB, we force step navigation always, overriding the browser
              // navigation between input elements, buttons and links.
              if ( event.keyCode === 9 ) {
                  return true;
              }
  
              // With the sole exception of TAB, we also ignore keys pressed if shift is down.
              if ( event.shiftKey ) {
                  return false;
              }
  
              if ( ( event.keyCode >= 32 && event.keyCode <= 34 ) ||
                   ( event.keyCode >= 37 && event.keyCode <= 40 ) ) {
                  return true;
              }
          }
docs: Supported keys are: [space] - quite common in presentation software to move forward [up] [right] / [down] [left] - again common and natural addition, [pgdown] / [pgup] - often triggered by remote controllers, [tab] - this one is quite controversial, but the reason it ended up on this list is quite an interesting story... Remember that strange part in the impress.js code where window is scrolled to 0,0 on every presentation step, because sometimes browser scrolls viewport because of the focused element? Well, the [tab] key by default navigates around focusable elements, so clicking it very often caused scrolling to focused element and breaking impress.js positioning. I didn't want to just prevent this default action, so I used [tab] as another way to moving to next step... And yes, I know that for the sake of consistency I should add [shift+tab] as opposite action...