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
