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 - [email protected] >>>>>> To unsubscribe, change settings or access archives, >>>>>> see http://fluidproject.org/mailman/listinfo/fluid-work >>>>> >>>> >>> >> >
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
