MelSumner · August 12, 2017 22:06
diff --git a/Things that are hard to do perfectly in A11y b/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).