add accessible specific code review checklist items, phetsims/gravity…

…-force-lab-basics#134

checklists/code_review_checklist.md

@@ -533,6 +533,11 @@ Because JavaScript lacks visibility modifiers (public, protected, private), PhET
 - [ ] Are all dependent properties modeled as `DerivedProperty` instead of `Property`?
 - [ ] All dynamics should be called from Sim.step(dt), do not use window.setTimeout or window.setInterval.  This will help support Legends of Learning and PhET-iO.
 
+## **Accessibility**
+- [ ] Are accessibility features integrated well into the code. They should be added in a maintainable way, even if that requires upfront refactoring.
+- [ ] Are accessible design patterns used, see [accessible-design-patterns.md](https://github.com/phetsims/phet-info/blob/master/doc/accessible-design-patterns.md)
+- [ ] Does resetting the simulation also reset the entire PDOM?
+
 ## **PhET-iO**
 
 - [ ] If the simulation is supposed to be instrumented for PhET-iO, please see [How to Instrument a PhET Simulation for PhET-iO](https://github.com/phetsims/phet-io/blob/master/doc/how-to-instrument-a-phet-simulation-for-phet-io.md)

doc/accessible-design-patterns.md

@@ -22,3 +22,12 @@ Common sections for each pattern:
   has keys pressed.
 
 
+### Describer Types
+
+Dynamic descriptions require a large amount of string formation based on model state. In general housing that logic
+in a `*Describer.js` type is helpful and idiomatic, where `*` is the purpose this particular describer has. Try not to 
+make a single general describer that has too much responsibility, for example `MolarityDescriber` in https://github.com/phetsims/molarity/issues/79
+
+Although describers don't need to be the only place where `StringUtils.fillIn` is used for accessible descriptions, 
+they can cover the majority of the usages, as well as keeping track of the model and custom state needed to create these
+descriptions.