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 - [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
