Connect.Tech

Web Accessibility

Will Jayroe - http://jayroe.com/wax/

• NVDA (close your eyes demo at beginning)
• also benefits users with slow and limited connectivity
• Spend the money first than it will if you retrofit accessibility afterwards
• Also benefits power users (liesure travel bookers in this case - equivalent for dealers using our sites possibly? - people searching for cars for other people - lawyers using TMV?)
• Section 508 for gov funded
• WCAG 2.0 Level AA Compliance for everything else
• Success Criteria (Success Criteria - Level A, AA, AAA)
• AA - standard that airlines and other are held to by government

• Conformance not compliance (because your trying to get close)
• Example of A to AA to AAA and notice contrast ratio differences but pleasingness
• Visual (most in depth)
• The others are more straight forward:
• Audio
• Physical
• Cognitive

• Repetitive items that cannot be skipped (one that I am missing from my shortlist?)
• Logical Flow - make sure your html is ordered properly in the markup and not using css reordering
• Skipping around (skip to content - quick links for screenreaders?)
• Non-text content (graphical and design elements - like charts and graphs)
• Nice very description alt text - 

• Tables can be tricky to get right for screen readers
• They had a hidden html table and skip the presentational table (challenging cause they had to maintain the content in two places)
• Use "skip-presentation" or something like that to skip
• JS - need to trigger screen reader to read text (angular and react have a lot of this built in)
• Be careful when adding access keys - better to build the page correctly
• WAI-ARIA descriptive tags can be added (a whole nother talk)

• Need to be able to browse with just a mouse (special keyboards pop up within text fields)
• Need to be able to browse with just a keyboard
• Be careful with modals and maintaining focus
• OpenDyslexic font - weight at bottom helps with dyslexia - https://opendyslexic.org
• Text on top of images
• Justified text can be difficult for people with cognitive disabilities
• Animations without meaning can be problematic

• WebAim WCAG Checklist
• No official certification only success criteria
• contrast ratio: http://leaverou.github.io/contrast-ratio/
• colorblindness for mac: https://itunes.apple.com/us/app/sim-daltonism/id693112260?mt=12

• Baseline testing
• keyboard - gets you really close
• screen reader - gets you almost there
• can never be all the way there
• if someone goes to your site and can do their task, you pass.  if they can't, you fail.
• chrome audits - youtube video https://www.youtube.com/watch?v=b0Q5Zp_yKaU

• companies state their intent
• give a way for people to submit bugs
• - explain features
• - known issues
• https://www.emirates.com/us/english/sitetools/accessibility.aspx
• https://www.delta.com/content/www/en_US/support/accessibility.html
• https://www.apple.com/accessibility/
• https://www.ibm.com/accessibility/us/en/
• https://www.microsoft.com/en-us/accessibility/default.aspx

https://www.deque.com/ - accessibility training

Recompose React Library

Jeff Barczewski - talk - library

• npm install compose
• the 'lodash' for React
• library for useful higher order component functions
• pure() - optimizations for re-rendering - shallow equals checks - componentWillUpdate?
• onlyUpdateForKeys() only will update if name or age changes - again optimization for re-rendering
• defaultProps() - quick way to change default props
• renameProp() easy ways to rename and adapt things
• withProps() - if you need to some calculations for your props
• withPropsOnChange() - optimization for calculating props
• compose() - like currying
• withState()
• withHandlers()

• branch - nice for loading state
• renderComoponent or renderNothing
• lifecycle

Robust Error Handling in Node.js

Lewis Ellis - talk

• have to be careful because catch won't catch anything in event loop (like setTimeout wrapped in catch)
• try/catch is sync - setTimeout is async (run-to-completion and event loop)
• An error in one request can take down the entire server

• Sometimes the only thing we can do is shut down and start from a good clean state again

• Error vs Exception
• Error in JS is just a special object class
• Exception is when you use a 'throw'
• You can pass around errors without a 'throw' (hence the difference in terminology)

• In Node, we're generally not going to throw exceptions, but we are going to pass around Error objects a lot

Guiding Principles

1. Always know when your errors happen
2. Handle what you can and avoid what you can't
   • Operational Errors vs Programming errors
   • Expected vs Unexpected
   • Recoverable vs Non
   • Operational
     • Network timeouts
     • DB down
     • Disk Full
     • 3rd party API returning errors
3. Don't keep running in an unknown state

• Handle any errors you can
• Have a global catch-all for the errors you couldn't handle
• Use a process manager so that shutting down is no bog deal
• Accept that when we have to restart, do everything you can to save logs and data

• try/catch
• callbacks
• promises
• async/await
• EventEmmiters
• Express (common library patterns)
  • next(err) and error-handling middleware
• try/catch with async/await isn't a silver bullet because there can be additional async tasks from within the async method

• Servers, Sockets, Requests, Streams
  • They can emit error events... listen for them!
• Express
  • app.use() to specify how to handle errors

• Global Error Handler
  • process.on()

• Process managers
• Run multiple processes so that if one has to shut down, you can keep serving your website
• systemd, pm2, forever, naught

• When we catch a fatal error
  • Quite accepting new connections
  • start reporting whatever we will need
  • tell proc manager we're gonna die so it starts replacement
  • wait for any existing requests/socets/etc
  • close any open resources and connects (like to a DB)
  • Shut Down

• What not to do with a global catch-all
  • Just log the error and carry on
  • Keep the process running indefinitely
  • Try to recover in any way (it's too late!)
  • Try to centralize handling of operational errors into one place - by they time we get to here, we just need to shut down

• Other global error mechanisms
  • process.on('uncaughtException')
  • process.on('unhandledRejection') !!you might be missing failures from promises if you aren't looking for these!!
    • currently non-fatal, warning starting in Node 7
    • future: fatal, will cause process exit
  • Domains: application code shouldn't need them - node team is trying to get rid of these - don't use them

• Other things not covered today
  • Run-to-completion semantics and the event loop
  • V8 stacktrace API
  • the "callback contract"
  • aynchronous stacktraces - expensive to run in prod, but much more information - node 8.5 (or.6) has a runtime flag for this
  • Cluster module & process managers
  • Domains
  • async_hooks (!!!!!) - will replace domains
• https://www.joyent.com/node-js/production/design/errors
• https://nodejs.org/api/errors.html

Accessibility

Nick Heiner - talk

• dyslexia simulation
• screen, magnifiers
• dragon - voice controller (when no keyboard or mouse at all)
• You can do this, but you'll never be perfect.
• WAI-ARIA
• *Do user research with disabled users*
• Scanning of sighted scanning using screenshot and arrows
• don't repeat that this is an image in the alt text
• alt="" for images we don't want read by the screenreader
• Don't use links with the word "here".  Use link text to be the thing you will take users to.

• recommended: don't use tabindex - maintenance nightmare - doesn't work with component based pages
• ARIA
  • roles - what an element is (role="button")
  • attributes - ways to decorate element ()
  • aria-live="polite" (live-updating content like chat bot)
• landmarks (like role="main,banner,search")
• aria-labelledby="table-title" (look at example slide)
• aria-hidden (great for modals) - aria-hidden="true" for everything that is not in the modal (problem if modal is nested)
• aria invalid label (for forms)
• setting language demo (czech example)
• *use screen-reader-only selector sparingly*
• skip links (visually hidden links for screen readers only)

• Testing for accessibility
• accessibility is more important than compliance
• don't just check boxes on a checklist
• nothing beats actual disabled users testing your app
• passing score on dev tool audit is a starting point
• Assisitive Technology process similar to browser declaration
• Testers must understand assistive tech
• Hard to know if your app has a problem, or that you just don't know how to use the tool
• devs must be able to test (even if it's not the exact tool)
• by making markup really specific for one screenreader you can actually cause more problems in the long run, instead write standard/complient code

React Performance

Sia Karamalegos

• always bind event handlers before render (use arrow functions because of this scoping) - if you do this wrong, react might be re-rending your component when it doesn't need to
• immutible friends
  • spread opperator
  • Object.assign
  • map and filter, not push and pop

React Performance

Sia Karamalegos

Only do if you have performance problems

• Avoid reconciliation when unnecessary?????
  • shouldComponentUpdate or use PureComponent instead
  • http://jamesknelson.com/should-i-use-shouldcomponentupdate/
  • https://facebook.github.io/react/docs/optimizing-performance.html
• Memoize any computed props in Redux mapStateToProps
•  
• reselect npm package for memoization of state (createSelector)
  • seems similar to what we are already doing with LD
• react-addons-perf