MelSumner/Things that are hard to do perfectly in A11y

## Things that are hard to do perfectly in A11y
Acceptance criteria:
* must use semantic HTML
* must have the correct ARIA roles (when necessary)
* must read out in a logical manner when assistive technology (AT) is used
* must use Ember correctly

Challenging UI Components:
[ ] radio button label contains a dropdown with options in it. Speech viewer should read entire thing correctly.
[x] a dropdown menu where the last X number of items are not interactive (menuitems), but are simply additional text items (i.e., "Last Login" type of info)
[ ] a data table that keeps semantic html
-- completely keyboard navigable- arrow keys, page up/down, home/end, ctrl + home/end
--- note: keyboard navigation for grids is different when screen readers are turned on
-- can be simple, heirarchical or nested
-- rows can be selectable via checkboxes or radiobuttons
-- records could be pre-selected, disabled, or readonly
-- columns could be sortable (tristate)
-- column width can be customized in the component
-- data can be either paginated or progressively loaded (but progressive loading must be done in an accessible way)
-- data could be filtered
-- data could be refreshed
-- correct information should be read to the user with assistive technology when the grid loads
-- information should be read to the user with assistive technology when the grid refreshes, any counts update, or other changes occur
-- should be visually presented in a device agnostic way
-- no data may be presented to be meaningful only through color
[ ] two lists where items can be moved between them using a keyboard only.
-- a user with a mouse could click and drag the same items.
-- any of the items in the list can have sub-elements.
-- any of the sub elements could be moved from one list to the other with the parent element.
[ ] the progress indicator (step one, step 2, etc) on the top of a form that functions sort of like a progressbar (but not really. lots of gotchas here).
	Acceptance criteria:
	* must use semantic HTML
	* must have the correct ARIA roles (when necessary)
	* must read out in a logical manner when assistive technology (AT) is used
	* must use Ember correctly

	Challenging UI Components:
	[ ] radio button label contains a dropdown with options in it. Speech viewer should read entire thing correctly.
	[x] a dropdown menu where the last X number of items are not interactive (menuitems), but are simply additional text items (i.e., "Last Login" type of info)
	[ ] a data table that keeps semantic html
	-- completely keyboard navigable- arrow keys, page up/down, home/end, ctrl + home/end
	--- note: keyboard navigation for grids is different when screen readers are turned on
	-- can be simple, heirarchical or nested
	-- rows can be selectable via checkboxes or radiobuttons
	-- records could be pre-selected, disabled, or readonly
	-- columns could be sortable (tristate)
	-- column width can be customized in the component
	-- data can be either paginated or progressively loaded (but progressive loading must be done in an accessible way)
	-- data could be filtered
	-- data could be refreshed
	-- correct information should be read to the user with assistive technology when the grid loads
	-- information should be read to the user with assistive technology when the grid refreshes, any counts update, or other changes occur
	-- should be visually presented in a device agnostic way
	-- no data may be presented to be meaningful only through color
	[ ] two lists where items can be moved between them using a keyboard only.
	-- a user with a mouse could click and drag the same items.
	-- any of the items in the list can have sub-elements.
	-- any of the sub elements could be moved from one list to the other with the parent element.
	[ ] the progress indicator (step one, step 2, etc) on the top of a form that functions sort of like a progressbar (but not really. lots of gotchas here).