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