Accessibility Minutes 2015 09 11

From MemberWiki

Jump to: navigation, search

Contents

Present

  • Jon Gunderson (University of Illinois) - Chair
  • Mike Scott (State of Illinois)
  • Nicholas Hoyt (University of Illinois)
  • Marc Johlic (IBM) (scribe)

Agenda


TOPIC: New FAE rule: "Interactive functionality must be keyboard operable"

http://fae20-dev.cita.illinois.edu/rulesets/rc/rule/KEYBOARD_2/


JG: Comes from WCAG 2.1.1


MS: Maybe change to ".. through keyboard commands"


NH: "keyboard interface" comes from WCAG so we used that, but will consider.. Whatever makes most sense. Will evolve over time


MS: Being consistent w/ WCAG is best


JG: Techniques section


MS: Surprised to see first bullet: "Avoid using tabindex values greater than 0 to change tabbing order, since tabbing behavior is inconsistent and therefore unpredictable across web browsers." Other than tabindex being a pain, are there cases where tabindex is not allowed


MJ: Surprised to see that one there too


JG: It can be removed


MS: "Ensure that interactive elements are in the tab order"


MS: Need to have both - must be focusable and have a keyboard event handler


JG: But if you have aria-activedecendent ..


NH: We do have a focus order rule


JG: Interesting thing about HTML5 is that all elements regardless of what they are have a default tabindex -1. IN the spec, that's what HTML5 browsers are supposed to do


JG: I think we have this covered under Focus Order


NH: Wonder if first technique should be deleted: "Avoid using tabindex values greater than 0 to change tabbing order, since tabbing behavior is inconsistent and therefore unpredictable across web browsers."


NH: This rule is testing if there are event handlers and has tab order been set explicityly


JG: In my notes I have that we should change that


NH: Inconsistent behavior - that phenomenon is address if "Focus Order must be meaningful" rule

TOPIC: Topic: Link 1 Rule

JG: Link 1 Rule

http://fae20-dev.cita.illinois.edu/rulesets/rc/rule/LINK_1/


JG: Link 1 "Link text must describe the link target"


JG: Changes were using the term "accessible name" and we updated the informational links


NH: Techniques are put in a different order than what are in the JS file.. First and last techniques should be swapped. Not sure why FAE is doing that switch


NH: Actually it looks like they are in the opposite order - 4, 3, 2, 1 vs 1 2 3 4 .. Listed techniques are backwards. Need to see why FAE is reversing them.


NH: Important that they be in order - as it shows the progression


JG: Will take a look at FAE


MS: The word "described" - wonder if "indicate" would be a better word to use in the Rule title


NH: A lot of this was pulled from the Informational links, but think "indicate" is a better word


JG: Covered Frame 1 and Frame 2 last week - all OK


NH: Not sure if I made the "role="presentation"" change. Jon believe you were going to test that on iframe


JG: I did not test that yet


JG: Just manual checks that anything marked up as a list is semantically a list

TOPIC: List 1

http://fae20-dev.cita.illinois.edu/rulesets/rc/rule/LIST_1/


NH: Last week Mike raised some questions about using the term "semantic"


MS: "Meaning" was the best alternative I could come up with.. Semantic is OK, but some folks may not understand


JG: List 1: Use semantic markup for lists


JG: Manual check - highlights list items on the page

TOPIC: List 2 Provide list labels when appropriate

http://fae20-dev.cita.illinois.edu/rulesets/rc/rule/LIST_2/


JG: We may need some examples


JG: Would help to show people where it's useful and not

TOPIC: Landmark 19 Landmarks must be descriptive

http://fae20-dev.cita.illinois.edu/rulesets/rc/rule/LANDMARK_19/


NH: We also need to talk about rules we deleted. We've only deleted 2 or 4


NH: Got rid of them because we didn't want users manually checking the appropriateness of whether the language made sense


JG: For example a headings rule - it was a manual check - to ensure the language was correct


NH: "Landmarks must identify regions on a page" (proposed) instead of "Landmarks must be descriptive"

TOPIC: Image 6 Verify text alternatives for images

http://fae20-dev.cita.illinois.edu/rulesets/rc/rule/IMAGE_6/


NH: Have not done the review and editing yet


JG: Summary is new


JG: Again trying to take language from WCAG. Enumerates more the concept of short and long description


JG: 3 possibilities for an image: 1) decorative, 2) only has a short desc, 3) has short and long desc


JG: Should images that are decorative be in a separate rule?


JG: Reason to break up into 2 rules is that it's easier to describe what the rule is doing.


MS: Is there a counter-argument to breaking it up? Will breaking it up clutter up the report? Would 1 image get reported 3 times


JG: No, only one rule for which it fell into (decorative or has an alt)


JG: We already have one rule that requires an alt on images (Rule 1)


JG: This Rule 6 is to verify that the alt assigned to the image is correct (null, short or long)


JG: Having that separate rule that pulls up all alt="" (null) would help verify that they were properly marked up as null

TOPIC: Order 1 Reading order must be meaningful

http://fae20-dev.cita.illinois.edu/rulesets/rc/rule/ORDER_1/


JG: We can talk about Order 1 next week. Nick is still working on it


JG: Similar to a Table rule we have - if we're just highlighting the sectioning elements is may be doable. What do people think about limiting a reading order rule to just sectioning elements?


JG: How are you testing reading order today?


MJ: We have a visualization tool - use that and a screen reader


NH: Similar - use a screen reader


NH: Something to consider is what would we miss by focusing on HTML 5 definition of sectioning elements (i.e would be miss a <body> of

tags?) JG: Maybe just pull this rule out for now and work on it for 1.1 ruleset

Retrieved from "/member/wiki/Accessibility_Minutes_2015_09_11"
Personal tools