accessibility issues to think about
Justin Obara
obara.justin at gmail.com
Wed Sep 1 20:14:22 UTC 2010
Here are the notes from the a11y talk we had at today's dev meeting.
Inline Edit: Two Scenarios
1. Pick a meaningful role and use aria-describedby to further explain the interaction
2. Embed a toggle button after the editable text--text no longer gets focused, but the toggle button does instead. Text is still given "focused" style. The toggle button element will need enough of a label to make sense to the user
The toggle button can be invisible. It will be actionable by the keyboard, and will place focus styling on the text when tabbed to. The text itself will be actionable by the mouse, but not the keyboard.
Reorderer
1. Reorderer should be wrapped in an "application" role
2. dynamic messages need to be conveyed as aria status role
3. need some indication of the orientation--horizontal, vertical, 2D grid. Some verbiage describing orientation and interaction (maybe with aria-describedby or maybe some hidden text)
4. provide an indication of which cell we're in--a label is probably the most promising option
5. in the case of complex layouts, it's the before and after information that's really important to a screen reader user
6. tie into UI Options to allow the user to insert hard stops as well as to present grids as if they were linear lists
- Justin
On 2010-08-31, at 1:07 PM, Justin Obara wrote:
> Just sending out a reminder of the a11y talk that we will have tomorrow at 2pm eastern time.
>
> I'll be trying to set up a skype call; please ensure that I have you as a contact if you would like to participate.
>
> Thanks
> Justin
> On 2010-08-27, at 1:00 PM, Justin Obara wrote:
>
>> I'll try to set up a Skype call for the meeting this coming Wednesday. Could everyone who would like to join please let me know and make sure that I have you as a contact on Skype.
>>
>> Thanks
>> Justin
>>
>> On 2010-08-26, at 2:22 PM, E.J. Zufelt wrote:
>>
>>> Sep 1, and Skype work well for me. I can do Connect / IRC, but it is really a sub-optimal experience.
>>>
>>> Thanks
>>> Everett Zufelt
>>> http://zufelt.ca
>>>
>>> Follow me on Twitter
>>> http://twitter.com/ezufelt
>>>
>>> View my LinkedIn Profile
>>> http://www.linkedin.com/in/ezufelt
>>>
>>>
>>>
>>> On 2010-08-26, at 2:20 PM, Justin Obara wrote:
>>>
>>>> Sorry, about the date. It is September 1, which is the first Wednesday in September. Developer meetings usually happen every Wednesday and usually in connect. However for this meeting I think you are right, we should try to use a different system. Maybe we could try to setup a skype conference call or something.
>>>>
>>>> Thanks
>>>> Justin
>>>> On 2010-08-26, at 2:10 PM, E.J. Zufelt wrote:
>>>>
>>>>> Good afternoon,
>>>>>
>>>>> Which Wednesday in Sep?
>>>>>
>>>>> Also, I tweeted for standards on inline edit. The only response was from Steve Faulkner who refered me to the Fluid inline edit :) So, we might be leading the standardization of inline edit accessibility here.
>>>>>
>>>>> Will this be over Connect? Because it is a bit inconvenient to participate in a conversation where others can talk and I can only type in the IRC channel.
>>>>>
>>>>> THanks,
>>>>> Everett Zufelt
>>>>> http://zufelt.ca
>>>>>
>>>>> Follow me on Twitter
>>>>> http://twitter.com/ezufelt
>>>>>
>>>>> View my LinkedIn Profile
>>>>> http://www.linkedin.com/in/ezufelt
>>>>>
>>>>>
>>>>>
>>>>> On 2010-08-26, at 2:03 PM, Justin Obara wrote:
>>>>>
>>>>>> At the next developer meeting, Wednesday Sept at 2pm, I think it would be a good idea to talk about these and any other a11y issues that come up on this thread.
>>>>>>
>>>>>> Does that time work for everyone, or should we schedule a specific meeting another time.
>>>>>>
>>>>>> Thanks
>>>>>> Justin
>>>>>>
>>>>>> On 2010-08-24, at 4:11 PM, E.J. Zufelt wrote:
>>>>>>
>>>>>>> On 2010-08-24, at 3:53 PM, Justin Obara wrote:
>>>>>>>
>>>>>>>> Hi Everett,
>>>>>>>>
>>>>>>>> This is an interesting topic, I think some of the designers might also have some thoughts on the interaction too. I'll add some comments in below.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Justin
>>>>>>>>
>>>>>>>> On 2010-08-24, at 1:10 PM, E.J. Zufelt wrote:
>>>>>>>>
>>>>>>>>> So, instead using the ARIA button role, can we just provide a text link (invisible) before the item with the text "Edit" or something more meaningful "Activate edit mode".
>>>>>>>>
>>>>>>>> In this case, would you then not focus on the inline editable element itself to access it. I think this maybe confusing to some users. But I'm not sure I'm understanding it correctly.
>>>>>>>
>>>>>>> I suppose this would be like a "isEditable" link, which sadly isn't in the current xhtml / ARIA API. But, essentially what we are looking for here is a method of clearly identifying that the text can be toggled into a mode in which it can be edited. E.g.
>>>>>>>
>>>>>>> <p>
>>>>>>> <a href="#" class="element-invisible">Click to edit following text</a>Some paragraph text here
>>>>>>> </p>
>>>>>>>
>>>>>>> You could still have the functionality bound to the click or enter on the paragraph, and on the anchor as well.
>>>>>>>
>>>>>>> Benefit:
>>>>>>>
>>>>>>> Screen-readers don't hear "button" at the end of each segment of text that is clearly not a button.
>>>>>>>
>>>>>>> Drawbacks:
>>>>>>> Sighted keyboard only, and screen-reader, users have one extra tabstop.
>>>>>>>
>>>>>>> Clearly the problem here is that we are trying 1. to create behavior that no web standard considers native to a web app. and 2. Trying to provide a textual affordance where the visual affordance is only present on the users prompting. This means that there will be more everpresent textual affordances as there is no clear way to make the affordance only available upon the users request.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Alternatively, can we make the item a same page link (a link seems more intuitive to me than a button for some reason.
>>>>>>>>
>>>>>>>> I suppose this should be doable, although we try not to prescribe the markup if possible.
>>>>>>>
>>>>>>> And now that I go back to look at the option I really feel more strongly for my first suggestion.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Everett Zufelt
>>>>>>>>> http://zufelt.ca
>>>>>>>>>
>>>>>>>>> Follow me on Twitter
>>>>>>>>> http://twitter.com/ezufelt
>>>>>>>>>
>>>>>>>>> View my LinkedIn Profile
>>>>>>>>> http://www.linkedin.com/in/ezufelt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2010-08-24, at 1:02 PM, Justin Obara wrote:
>>>>>>>>>
>>>>>>>>>> Hi Everett,
>>>>>>>>>>
>>>>>>>>>> Please see comments inline below.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Justin
>>>>>>>>>>
>>>>>>>>>> On 2010-08-24, at 11:30 AM, E.J. Zufelt wrote:
>>>>>>>>>>
>>>>>>>>>>> On 2010-08-24, at 10:11 AM, Justin Obara wrote:
>>>>>>>>>>>
>>>>>>>>>>>> In looking through some of our accessibility (a11y) issues, there are several that I believe could use a little more thought and/or discussion.
>>>>>>>>>>>>
>>>>>>>>>>>> FLUID-2964:
>>>>>>>>>>>> Research a11y best practices for re-orderer
>>>>>>>>>>>> http://issues.fluidproject.org/browse/FLUID-2964
>>>>>>>>>>>>
>>>>>>>>>>>> This covers issues such as how to describe the layout of the reorderable items.
>>>>>>>>>>>>
>>>>>>>>>>>> FLUID-2652:
>>>>>>>>>>>> JAWS announces that an inline edit area is a button
>>>>>>>>>>>> http://issues.fluidproject.org/browse/FLUID-2652
>>>>>>>>>>>>
>>>>>>>>>>>> There are no specific aria roles that describe the functionality of an inline editable field. The button role was originally chosen as it seemed the most appropriate, but it still can be confusing to screen reader users.
>>>>>>>>>>>>
>>>>>>>>>>> * What visual affordances are provided for inline edit fields 1) when inactive 2) when :hover 3) when :focus? This will help me to build a better mental model of how to translate the visual affordance to something textual.
>>>>>>>>>>
>>>>>>>>>> The visual affordances are of course, customizable, however I'll detail the default style. When it is inactive, in view mode, it appears like all of the other regular text on the page. On hover or focus, it will have some focus styling such as a border. After entering into edit mode (by clicking with the mouse of pressing the space or enter keys) it will appear as a standard text field.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> FLUID-985:
>>>>>>>>>>>> Convey the deletable and completed states for file rows
>>>>>>>>>>>> http://issues.fluidproject.org/browse/FLUID-985
>>>>>>>>>>>>
>>>>>>>>>>>> In the file queue for the uploader you are able to remove files from the queue until they have been uploaded. The title of the row was changed to read "File Uploaded" after it had been uploaded. However, this does not seem to work across all screen reader / browser configurations. Is this just a bug that needs to be addressed, or is there a better approach?
>>>>>>>>>>>>
>>>>>>>>>>>> There are more details to talk about, the above commentary is just a starter. Please let us know what your thoughts on the issues are and how we can adequately address them. For more a11y issues in Infusion you can take a look at the a11y filter we have in our jira repository.
>>>>>>>>>>>>
>>>>>>>>>>> * Is there a good time for a group chat on these issues?
>>>>>>>>>>
>>>>>>>>>> I'm not sure exactly, I think if you reply on list we should be able to work something out. Colin is away this week on vacation though, so we may have to wait till after that.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> http://issues.fluidproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=10320
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Justin
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________________
>>>>>>>>>>>> fluid-work mailing list - fluid-work at fluidproject.org
>>>>>>>>>>>> To unsubscribe, change settings or access archives,
>>>>>>>>>>>> see http://fluidproject.org/mailman/listinfo/fluid-work
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20100901/e144b8e6/attachment.htm>
More information about the fluid-work
mailing list