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