/
fluid-work IRC Logs-2010-03-10

fluid-work IRC Logs-2010-03-10

Mar 10, 2010

[08:52:55 EST(-0500)] * jhung (~Lynnette@H41.C195.cci.switchworks.net) has joined #fluid-work
[09:36:25 EST(-0500)] * yura (~Fluid@142.150.154.164) has joined #fluid-work
[09:37:12 EST(-0500)] * jameswy (~jameswy@142.150.154.196) has joined #fluid-work
[09:52:36 EST(-0500)] * clown (~clown@142.150.154.101) has joined #fluid-work
[10:17:55 EST(-0500)] * clown (~clown@142.150.154.101) has joined #fluid-work
[10:24:22 EST(-0500)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[11:46:18 EST(-0500)] * elicochran (~elicochra@dhcp-169-229-212-38.LIPS.Berkeley.EDU) has joined #fluid-work
[12:04:47 EST(-0500)] * EricDalquist (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined #fluid-work
[12:46:50 EST(-0500)] * colinclark (~colin@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[12:47:12 EST(-0500)] <colinclark> I filed this bug this morning, and then attached a patch to it: http://issues.fluidproject.org/browse/ENGAGE-506
[13:04:59 EST(-0500)] * elicochran (~elicochra@doecev-wlan2-150-179.AirBears.Berkeley.EDU) has joined #fluid-work
[13:07:32 EST(-0500)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[13:21:30 EST(-0500)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[13:29:00 EST(-0500)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[13:46:41 EST(-0500)] * colinclark (~colin@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[13:59:19 EST(-0500)] * greggy (~greg@142.150.154.79) has joined #fluid-work
[14:08:15 EST(-0500)] <michelled> yura: can this JIRA be closed now? http://issues.fluidproject.org/browse/ENGAGE-495
[14:24:16 EST(-0500)] <michelled> colinclark: I think you fixed this issue with the use of jQuery hashchange, am I right? http://issues.fluidproject.org/browse/ENGAGE-230
[14:25:01 EST(-0500)] <colinclark> michelled: Yep. I'm resolving the issue now
[14:25:04 EST(-0500)] <colinclark> Can you review and close it?
[14:25:10 EST(-0500)] <michelled> sure
[14:26:19 EST(-0500)] <colinclark> michelled: resolved
[14:26:34 EST(-0500)] <colinclark> the hash change plugin is a slightly awkward solution, but it does work quite nicely
[14:27:11 EST(-0500)] <colinclark> On browsers that aren't IE 8 or FF 3.6, it has to run a timer that periodically checks the window.location.hash to see if it has changed. At that point, it fires an event
[14:27:38 EST(-0500)] <colinclark> So we pay a small cost on the iPhone to run this timer, but it means that we get nearly idiomatic back button support
[14:27:38 EST(-0500)] <yura> http://issues.fluidproject.org/browse/ENGAGE-495 is resolved
[14:29:52 EST(-0500)] <michelled> colinclark: the app has become so much faster with the screen navigator that I don't think the cost of the timer is even apparent.
[14:30:22 EST(-0500)] <colinclark> I think with the removal of the broken document.readystatus timer, we're probably a bit faster, too
[14:30:29 EST(-0500)] <colinclark> I'll have to fill you in on the whole saga at some point
[14:30:48 EST(-0500)] <colinclark> But the take-away message is to never believe what you read on someone's blog, even if it's posted to Ajaxian
[14:30:58 EST(-0500)] <colinclark> And even, sometimes, jQuery is quite wrong
[14:31:06 EST(-0500)] <michelled> (sad)
[14:33:12 EST(-0500)] * greggy (~greg@142.150.154.79) has left #fluid-work
[14:36:55 EST(-0500)] * colinclark (~colin@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[14:37:54 EST(-0500)] <colinclark> athena is doing a presentation and showing off uPortal's use of Infusion
[14:38:00 EST(-0500)] <michelled> (smile)
[14:38:01 EST(-0500)] <colinclark> Great overview of the FSS, of the Pager, and more
[14:39:08 EST(-0500)] <colinclark> She's being very sweet
[14:54:48 EST(-0500)] <colinclark> michelled: Shall I go ahead and delete the 0.3bx branch, then?
[14:59:07 EST(-0500)] <michelled> I think so - either that or we should merge trunk with it
[15:23:58 EST(-0500)] * jhung (~Lynnette@H41.C195.cci.switchworks.net) has left #fluid-work
[15:25:36 EST(-0500)] * yura (~Fluid@142.150.154.164) has left #fluid-work
[15:29:45 EST(-0500)] * yura (~Fluid@142.150.154.164) has joined #fluid-work
[15:50:15 EST(-0500)] * colinclark (~colin@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[16:06:15 EST(-0500)] * colinclark (~colin@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[16:57:18 EST(-0500)] * colinclark (~colin@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[17:02:07 EST(-0500)] * athena (~athena@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[17:20:58 EST(-0500)] * clown (~clown@142.150.154.101) has left #fluid-work
[17:28:49 EST(-0500)] * Bosmon (~Bosmon@eccr224-158-dhcp.colorado.edu) has joined #fluid-work
[17:29:02 EST(-0500)] <Bosmon> yura: You there?
[17:53:12 EST(-0500)] * anastasiac (~team@142.150.154.193) has left #fluid-work
[18:44:20 EST(-0500)] * athena (~athena@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[19:36:03 EST(-0500)] * athena (~athena@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[20:58:52 EST(-0500)] * athena (~athena@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[21:38:29 EST(-0500)] * michelled (~michelled@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[04:06:45 EST(-0500)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[04:35:19 EST(-0500)] * sveto (~sveto@62.44.108.2) has joined #fluid-work
[06:14:32 EST(-0500)] * sveto (~sveto@62.44.108.2) has left #fluid-work
[08:16:30 EST(-0500)] * jhung (~Lynnette@H41.C195.cci.switchworks.net) has joined #fluid-work
[08:28:24 EST(-0500)] <jhung> Boyan, at the bottom fo this page I added some notes about the python script for tiff to pdf. http://wiki.fluidproject.org/display/fluid/Decapod+Ubuntu+Packages
[08:28:47 EST(-0500)] * sveto (~sveto@62.44.108.2) has joined #fluid-work
[08:29:49 EST(-0500)] <boyan> thanks, jhung, is that the script Michael and Joost will provide
[08:31:25 EST(-0500)] <jhung> Yes I think so. Tom cautioned that the arguments and switches may change to make it easier to type in command line, but basically the same functionality.
[08:31:40 EST(-0500)] <boyan> ok, thanks again
[09:02:52 EST(-0500)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[09:23:19 EST(-0500)] * jameswy (~jameswy@142.150.154.196) has joined #fluid-work
[09:45:06 EST(-0500)] * clown (~clown@142.150.154.101) has joined #fluid-work
[09:55:12 EST(-0500)] * EverettZ (~chatzilla@bas4-toronto06-1242458424.dsl.bell.ca) has joined #fluid-work
[09:55:40 EST(-0500)] <EverettZ> morning
[09:59:23 EST(-0500)] <sveto> hi EverettZ
[10:01:08 EST(-0500)] <sveto> EverettZ: maybe we should wait for yura and Tona to show up?
[10:02:08 EST(-0500)] <EverettZ> sveto: sounds like a good idea.
[10:05:37 EST(-0500)] * michelled_ (~michelled@142.150.154.141) has joined #fluid-work
[10:06:46 EST(-0500)] <EverettZ> sveto: Tona just pinged the mailing list saying there were some IRC connection problems, should be here in a minute
[10:07:21 EST(-0500)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[10:08:02 EST(-0500)] * tona_ (~tonamonjo@202.Red-80-37-183.staticIP.rima-tde.net) has joined #fluid-work
[10:09:58 EST(-0500)] <EverettZ> Good morning Tona
[10:10:06 EST(-0500)] <tona_> good morning!
[10:10:16 EST(-0500)] <tona_> I'm sorry, I had some problems to connect until now
[10:10:24 EST(-0500)] <tona_> have you started?
[10:10:36 EST(-0500)] <EverettZ> tona_: not yet
[10:10:45 EST(-0500)] <tona_> ok
[10:10:45 EST(-0500)] <yura> hi everyone , sorry , i had to step out
[10:11:06 EST(-0500)] <tona_> sure it will be interesting for design issues
[10:11:08 EST(-0500)] <EverettZ> Looks like we're all here now.
[10:11:14 EST(-0500)] <tona_> yes
[10:11:28 EST(-0500)] <sveto> yes
[10:12:16 EST(-0500)] <yura> yes
[10:13:22 EST(-0500)] <sveto> so, what I've been trying to accomplish is to make the blank text in code entry screen announced by voice over, before that other issues where outlined, from my list:
[10:13:35 EST(-0500)] <EverettZ> perhaps someone can start by giving a description of the problem, so that we're all on the same page, particularly me.
[10:13:48 EST(-0500)] <sveto> refresh dynamic text elements in voice over
[10:14:00 EST(-0500)] <sveto> announce alerts (for code entry screen)
[10:14:18 EST(-0500)] <sveto> announce content of modal dialogs and allow navigation inside them
[10:15:05 EST(-0500)] <EverettZ> I've done some research into modal dialogs, screen-readers at present don't like them
[10:16:19 EST(-0500)] <EverettZ> I posted an article about this at http://zufelt.ca/article/Can-a-modal-dialog-be-made-to-work-properly-for-screen-reader-users-on-the-web
[10:16:49 EST(-0500)] <jhung> michelled_ will you be coming to the Deca meeting @ 11a?
[10:17:05 EST(-0500)] <yura> i was looking into it as well, but for voice over specifically in saphari and found that dynamic content in web apps is generally inaccessible by it
[10:18:20 EST(-0500)] <yura> the only way to announce something new is to focus the voice over cursor on the element and that is pretty bad
[10:18:21 EST(-0500)] <EverettZ> The problem for VoiceOver is that it doesn't move focus to the dialog, and doesn't let the user understand the separation of content between the dialog and it's parent
[10:19:09 EST(-0500)] <EverettZ> Correct, VO / Safari don't support the application or live region roles
[10:19:54 EST(-0500)] <yura> EverettZ: I found that with voice over, even if you load a new page after following the link , the cursor in the voice over stays on the previous page unless you explicitely focus on the new one , I was wondering how did you manage to navigate through the engage app when testing?
[10:19:56 EST(-0500)] <michelled_> jhung: sure I can join it
[10:21:00 EST(-0500)] <EverettZ> yura: I wait for the Web page loaded announcement and then tap the screen to put focus on the new page
[10:21:16 EST(-0500)] <yura> oh so you are using it not in chromeless mode?
[10:21:45 EST(-0500)] <yura> in your case i m assuming it will automatically focus on the url , right?
[10:21:46 EST(-0500)] <jhung> _michelled. Cool! It's going to be a short meeting, but do you think you can give an overview of what happens after open coding?
[10:21:53 EST(-0500)] <yura> sveto: by the way, have you managed somehow to make those digit fields tabbable or focusable with voce over?
[10:22:11 EST(-0500)] <michelled_> sure jhung
[10:22:11 EST(-0500)] <EverettZ> correct, I am not using chromeless mode
[10:22:33 EST(-0500)] <jhung> muchas gracias michelled_
[10:22:39 EST(-0500)] <michelled_> np
[10:22:40 EST(-0500)] <sveto> yura: yes, by putting them in <a> tags, but again focus should be set manually
[10:23:25 EST(-0500)] <yura> i see, yes, in chromeless mode there's no announcement of the new page loaded at all and no refocusing, so the new page becomes the dynamic content (smile)
[10:23:42 EST(-0500)] <EverettZ> yura: once the new page is loaded and I tap the screen to give the new page focus the focus is on whatever element I happen to tap
[10:23:57 EST(-0500)] <yura> sveto: oh right, so simpy putting tabindex will not work
[10:24:48 EST(-0500)] <EverettZ> Can someone explain the expected functionality of the code entry screen?
[10:24:57 EST(-0500)] <yura> EverettZ: sure
[10:25:13 EST(-0500)] <tona_> EverettZ: so from the design point of view, we should replace all modal dialogs by new pages, isn't it?
[10:26:24 EST(-0500)] <yura> the object code enty screen has 3 main regions , the notification/instruction message, 2 digit display and the number key pad
[10:26:48 EST(-0500)] <yura> in the key pad you can sequentially enter the object code (currently valid codes are from 01 to 10)
[10:27:17 EST(-0500)] <yura> once you entered 2 digits it redirects you to an artifact view page
[10:27:49 EST(-0500)] <EverettZ> What happens if you enter an invalid code?
[10:28:54 EST(-0500)] <yura> the notification message will change to saying that the code is invalid
[10:29:10 EST(-0500)] <yura> it will stay there until you enter the correct code and get redirected or leave the page
[10:29:15 EST(-0500)] <EverettZ> And where does the dialog come into play?
[10:29:33 EST(-0500)] <yura> there's no dialog on that page actually , i think , is that right , sveto?
[10:29:39 EST(-0500)] <sveto> yes, the dialog is in the My Collection screen
[10:31:02 EST(-0500)] <EverettZ> So, from an accessibility standpoint users need to 1. be able to confirm the code that they have entered, 2. be able to access the error message (even it they have to hunt for it themself) and 3. be able to disable the auto-redirect and have the ability to have a UI component to direct themself.
[10:31:49 EST(-0500)] <yura> EverettZ: so some submission action before proceding to the artifact page?
[10:32:17 EST(-0500)] <EverettZ> yura: yes, but not as a default behaviour, as a user definable behaviour
[10:32:53 EST(-0500)] <EverettZ> yura: it can be default, but that is not necessary to satisfy WCAG
[10:33:45 EST(-0500)] <yura> EverettZ: thanks, and I also think that even now the notification can be found on that page, however if it changes it has to be focused on to be updated in the voice over
[10:34:03 EST(-0500)] <yura> tona_: is that a possibility from the design perspective on that page?
[10:34:11 EST(-0500)] <yura> i mean the submit action
[10:34:51 EST(-0500)] <tona_> yes, we will include an option to submit the code
[10:35:13 EST(-0500)] <tona_> instead of the current default behaviour
[10:36:36 EST(-0500)] <EverettZ> So, as I understand it, dynamic content, like the error message and entered code, are not visible to VO unless the user refocuses the page. Is that correct?
[10:36:45 EST(-0500)] <yura> yes
[10:36:59 EST(-0500)] <yura> actually not the page but the actual dynamic element
[10:37:26 EST(-0500)] <yura> I was comparing a number of web apps (from Google, etc.) and all of them have the same issue
[10:37:51 EST(-0500)] <EverettZ> yura: Ok, then 1. the ability to disable the default redirect action is manditory, and 2. we need to provide instructions to users about this being required. It is a current flaw with VO / Safari on the iPhone.
[10:38:21 EST(-0500)] <EverettZ> yura: The instructions don't have to be part of the UI, but we need to find a way to delive the information to users.
[10:38:39 EST(-0500)] <yura> can it be something that is visible to voice over only?
[10:38:54 EST(-0500)] <EverettZ> The problem should also be reported with as much detail as possible to accessibility@apple.com, who in my experience are quite responsive.
[10:39:10 EST(-0500)] <yura> EverettZ: yes, that's a good idea
[10:39:32 EST(-0500)] <EverettZ> We can put the instructions off-screen, but it should also be part of any external documentation / instructions to museum staff.
[10:39:42 EST(-0500)] <yura> also there is an accessibility issue on the artifact page. EverettZ: whenever you collect an artifact there's actually a temporary sliding notification/link to my collection that you can click on and be redirected, it's only there for 10seconds and then it hides again, do you have any suggestions about that?
[10:41:41 EST(-0500)] <EverettZ> yura: hmmm, I would say that it isn't important to worry about at this time, as VO / Safari are not going to play well with most solutions, and there is an alternative method for users to get to the My Collection page from the homepage
[10:42:00 EST(-0500)] <yura> thanks
[10:42:10 EST(-0500)] <yura> overall, there's only one place where I noticed a focus being intercepted and it is actually a jquery ui dialog that we use in my collection page, whenever it opens the focus shifts to the input text field
[10:42:35 EST(-0500)] <yura> and it's being announced by the voice over
[10:42:54 EST(-0500)] <EverettZ> yura: However, for non-VO users, we might want a general UI setting somewhere to disable these time-based events, or to prolong the time
[10:43:35 EST(-0500)] <EverettZ> How many places in Engage is jQuery dialog being used?
[10:43:51 EST(-0500)] <yura> yes, Colin was already suggesting that, maybe tona_ you have some ideas for that?
[10:44:04 EST(-0500)] <yura> 1 place and it's on my collection page
[10:44:51 EST(-0500)] <EverettZ> yura: Can you explain the functionality, why does it appear and what does it do?
[10:44:59 EST(-0500)] <yura> sure, sorry
[10:45:19 EST(-0500)] <yura> so whenever you collected 1 or more artifacts you will have a send button on my collection screen
[10:45:40 EST(-0500)] <EverettZ> yura: the ability to prolong timed events is less important, but still important, when there is an alternative method to perform te same action.
[10:47:11 EST(-0500)] <jameswy> EverettZ: about having a submit button on the code entry: the convention for many applications (iPhone or otherwise), is to automatically accept the number without a submit button if the length of the number is known. Examples: 1) the code lock screen on the iPhone doesn't use a submit button, 2) entering a phone number on regular land-line phones, 3) entering your ATM code at a bank machine. Is this submit-less mode of interaction inherently inaccess
[10:47:11 EST(-0500)] <jameswy> (you can get to this question after the current conversation thread is over)
[10:47:23 EST(-0500)] <yura> if you tap or click on that button jquery dialog will appear that will prompt you to enter your email address in the text input field that will have the focus and then you would have 2 options of cancelling or submitting the email that will both close the dialog. Submit action will send the email with your collection
[10:48:15 EST(-0500)] <EverettZ> yura: just going to test, 1 sec
[10:48:29 EST(-0500)] <yura> EverettZ: thanks
[10:49:22 EST(-0500)] <EverettZ> jameswy: I suppose it depends on the ability for an unexpected action to happen automatically upon an incorrect entry. I.e. entering the incorrect code will not automatically unlock the phone, entering an incorrect object code will automatically take you to the wrong page.
[10:52:08 EST(-0500)] <jameswy> EverettZ: True, though this is a problem present for both sighted and unsighted users and represents the negative tradeoff of having the convenience of a submit-less entry (for instance, one doesn't think to press "enter" after dialing a phone number on a landline). Is there anything specific about this mode of interaction that's inaccessible for unsighted users?
[10:53:14 EST(-0500)] <EverettZ> jameswy: It's less a concern for unsighted usrs, more of a concern for users who interact with a UI more slowly than average. I would argue that the landline phone, if it were considered a UI, might fail the WCAG success criteria on this point (smile)
[10:53:41 EST(-0500)] <jameswy> EverettZ: roger that. Thanks!
[10:55:12 EST(-0500)] <sveto> I apologize, but I have to go... I'll read the channel log later today, the converstation so far was very helpful
[10:55:20 EST(-0500)] <tona_> jameswy: and I think there's another difference: entering code numbers for unlocking anything don't move you to another page, but our code does
[10:55:59 EST(-0500)] <tona_> changes the user's context
[10:56:08 EST(-0500)] * sveto (~sveto@62.44.108.2) has left #fluid-work
[10:56:16 EST(-0500)] * EricDalquist (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined #fluid-work
[10:56:26 EST(-0500)] <jameswy> tona_: I think entering code numbers for unlocking things typically does move you to another page--the unlock screen on my iPod touch looks very different than my home screen, (smile)
[10:57:01 EST(-0500)] <jameswy> But I understand what you mean--in a way, code unlock is just unwrapping what's underneath
[10:57:06 EST(-0500)] <tona_> yes, but when you unlock, you see your home screen again
[10:57:30 EST(-0500)] <tona_> yes, you keep in the same place, in some sense...
[10:58:02 EST(-0500)] <yura> EverettZ: so were you able to access the dialog on my collection page?
[10:58:05 EST(-0500)] * athena (~athena@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[10:58:22 EST(-0500)] <EverettZ> yura: yes
[10:58:36 EST(-0500)] <EverettZ> 1. VO recognizes the dialog and moves focus to the input field
[10:59:07 EST(-0500)] <EverettZ> 2. The cancel button dismisses the dialog, but VO doesn't recognize this until you refocus the page.
[10:59:27 EST(-0500)] * boyan (~boyan@62.44.108.2) has left #fluid-work
[10:59:44 EST(-0500)] <EverettZ> 3. There is an unlabelled button at the top of the dialog, which doesn't appear to cancel the dialog like the cancel button does, don't know what this does.
[11:00:06 EST(-0500)] <jhung> michelled_ we're meeting on Skype
[11:00:19 EST(-0500)] <EverettZ> 3. The label doesn't appear to be programatically associated with the input field, VO doesn't read the label for the field
[11:00:33 EST(-0500)] <EverettZ> Didn't try sending the collection
[11:02:42 EST(-0500)] <yura> EverettZ: i think that anounced button on top is the hiden defulat close dialog button
[11:07:32 EST(-0500)] <EverettZ> So, if we can address the label or title attribute for the text field, I think that this particular implementation of jQuery dialog is as accessible as we can expect using VO / Safari
[11:08:20 EST(-0500)] <yura> EverettZ: thanks, that's something we can certainly add
[11:11:15 EST(-0500)] <EverettZ> yura: Anything else that I can help with this morning?
[11:13:50 EST(-0500)] <EverettZ> For anyone interested, there is an online petition to get the Government of Canada to stop discriminating against people by offering poorly / inaccessible web-sites at http://www.petitiononline.com/GCWAP/petition.html
[11:14:45 EST(-0500)] <EverettZ> The Government is currently defending itself against a s. 15 Charter (equality rights) challenge on this issue.
[11:15:09 EST(-0500)] <yura> hmm, well i think the vouce over cursor control seems like the biggest issue that's i found while looking in all the accessibility issues, and i think those 3 pages (my collection, artifact and object code) we discussed pretty well
[11:15:25 EST(-0500)] <yura> the rest of the pages have generally static content, i think
[11:16:09 EST(-0500)] <EverettZ> yura: Alright then, glad I could help. Let me know if there is anything else that I can do to help with any Fluid project
[11:16:37 EST(-0500)] <yura> thanks EverettZ, that was really helpful, I will submit the issue to apple accessibility soon
[11:16:56 EST(-0500)] <EverettZ> yura: excellent. Have a good day
[11:17:01 EST(-0500)] <tona_> thanks for letting me attend this chat
[11:17:08 EST(-0500)] <tona_> it's been really interesting!
[11:17:18 EST(-0500)] <tona_> bye!
[11:17:18 EST(-0500)] <yura> thanks guys , see you around
[11:35:30 EST(-0500)] * athena (~athena@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[11:39:57 EST(-0500)] * elicochran (~elicochra@dhcp-169-229-212-90.LIPS.Berkeley.EDU) has joined #fluid-work
[11:50:26 EST(-0500)] * colinclark (~colin@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[12:16:15 EST(-0500)] <jamon> FIXED, WOOO!
[12:16:21 EST(-0500)] <jamon> slowness, begone with you..
[12:18:24 EST(-0500)] <colinclark> hey yura and jameswy
[12:18:30 EST(-0500)] <colinclark> jameswy: YOU ROCK!
[12:18:35 EST(-0500)] <jameswy> I do?
[12:18:40 EST(-0500)] <jameswy> I mean, of course!
[12:19:00 EST(-0500)] <colinclark> wait
[12:19:05 EST(-0500)] <colinclark> jamon: YOU ROCK!
[12:19:12 EST(-0500)] <colinclark> jameswy: Is pretty okay
[12:19:13 EST(-0500)] <colinclark> (smile)
[12:19:14 EST(-0500)] <jameswy> Lol
[12:19:45 EST(-0500)] <colinclark> So, jameswy and yura, I was catching up on the really interesting channel discussion
[12:19:53 EST(-0500)] <colinclark> A few interesting things struck me
[12:20:00 EST(-0500)] <colinclark> The notion of "inherently inaccessible"
[12:20:27 EST(-0500)] <colinclark> I imagine we might be hard pressed, if asked, to identify a particular interaction as "inherently usable"
[12:20:58 EST(-0500)] <colinclark> but we could certainly look at who are users are and what they want to accomplish, and see shades of this.
[12:21:40 EST(-0500)] <colinclark> I'm really glad Everett was able to emphasize a couple key points, including control over page transitions and animations
[12:22:12 EST(-0500)] <colinclark> I'd like to see us take advantage of UI Options and the user interface preferences that Jutta and I have proposed for the next draft of AccessForAll
[12:22:27 EST(-0500)] <colinclark> Giving users a gentle way to slow things down or exert a little extra control
[12:22:40 EST(-0500)] <colinclark> while still making it naturally awesome for those who don't need it.
[12:22:47 EST(-0500)] <colinclark> There were a few specific take-aways:
[12:23:34 EST(-0500)] <colinclark> 1. We need to file a bug about the fact that the form field in Send My Collection is not correctly labelled
[12:24:16 EST(-0500)] <colinclark> 2. We should escalate some of the issues we're experiencing with dynamic content and VoiceOver, especially in context of the all-in-one-page model, which Apple themselves advocate
[12:26:25 EST(-0500)] <colinclark> I think we should also generally avoid hiding instructions where possible, and perhaps introduce a Help section or something that enables everyone-people who are using ATs, museum staff supporting the app, etc.-to learn about how the app works in different contexts
[12:26:52 EST(-0500)] <jameswy> colinclark: That sounds about right to me.
[12:26:56 EST(-0500)] <colinclark> (smile)
[12:27:11 EST(-0500)] <jameswy> (also, agreed-"inherently inaccessible" wasn't a good way of framing it (my bad)-it's not nearly as morally black-and-white as that)
[12:28:02 EST(-0500)] <colinclark> jameswy: yeah, sorry. I wasn't trying to give you a hard time about that comment
[12:28:15 EST(-0500)] <colinclark> I was actually just thinking how interesting it was as a contrast to usability
[12:28:33 EST(-0500)] <colinclark> Which, similarly, ends up getting weighed against who the user is and what their goals are
[12:29:06 EST(-0500)] <colinclark> I think there are probably some subtle and elegant ways that we can allow users to adapt their experience based on needs
[12:30:04 EST(-0500)] <jameswy> I think so too--I'm excited to think about what UI options might look like on mobile.
[12:30:45 EST(-0500)] <colinclark> me too
[12:30:53 EST(-0500)] <colinclark> I think of UI Options as our last resort...
[12:30:54 EST(-0500)] <colinclark> in a good way
[12:31:05 EST(-0500)] <colinclark> Wherever we can do things in a "non-modal" way, that'll be better
[12:31:55 EST(-0500)] <colinclark> but where there's just a real distinction in styles of interaction, we can provide the user with some control in UI Options
[12:45:52 EST(-0500)] * colinclark (~colin@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[12:49:25 EST(-0500)] * colinclark_ (~colin@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[12:51:28 EST(-0500)] <colinclark> http://www.w3.org/WAI/WCAG20/quickref/
[13:01:47 EST(-0500)] * elicochran (~elicochra@dhcp-169-229-212-90.LIPS.Berkeley.EDU) has joined #fluid-work
[13:32:38 EST(-0500)] * greggy (~greg@142.150.154.79) has joined #fluid-work
[14:12:04 EST(-0500)] * elicochran (~elicochra@dhcp-169-229-212-90.LIPS.Berkeley.EDU) has joined #fluid-work
[14:14:43 EST(-0500)] * colinclark (~colin@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[14:17:49 EST(-0500)] * colinclark (~colin@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[14:57:58 EST(-0500)] * yura1 (~yura@user149-60.wireless.utoronto.ca) has joined #fluid-work
[14:59:10 EST(-0500)] * yura1 (~yura@user149-60.wireless.utoronto.ca) has joined #fluid-work
[15:05:02 EST(-0500)] * yura1 (~yura@user149-60.wireless.utoronto.ca) has joined #fluid-work
[15:24:28 EST(-0500)] * colinclark (~colin@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work
[15:38:24 EST(-0500)] * michelled (~michelled@142.150.154.141) has joined #fluid-work
[16:33:09 EST(-0500)] * colinclark (~colin@ip-66-181-1-6.cust.i2bnetworks.com) has joined #fluid-work