W3C home > Mailing lists > Public > public-aria@w3.org > May 2016

Re: 48 hour Call For Consensus regarding Resolutions from the May 19, 2016 ARIA Working Group meeting

From: James Nurthen <james.nurthen@oracle.com>
Date: Thu, 26 May 2016 09:35:07 -0700
To: public-aria@w3.org
Message-ID: <21d0c2c1-fb87-f496-9c9c-dedee35944bf@oracle.com>
Rich,

This is not my argument - I think you have me mixed up with others on 
this thread.

Regards,

james

On 5/26/2016 8:44 AM, Rich Schwerdtfeger wrote:
> I agree, that is the problem. We only have a tree widget structure. 
> Saying that you can’t go into a treeitem is as much a non-start as not 
> being able to go into a grid cell.
>
> I also don’t agree with James Nurthen’s statement that putting a 
> button inside a tree item “will not work”.
>
> -  You can give it a tab index of “-1” and you can have a keyboard 
> shortcut to activate it.
> -  You could have a mode that puts you in the tree item (like we do 
> with grids) and navigate in the tree item.
>
> This is all JavaScript and it is completely doable.
>
> Sorry, I don’t buy the arguments requiring the descendants to be 
> presentational.
>
> Rich
>
> Rich Schwerdtfeger
>
>
>
>
>> On May 26, 2016, at 7:35 AM, Fred Esch <fesch@us.ibm.com 
>> <mailto:fesch@us.ibm.com>> wrote:
>>
>> Matt,
>>
>> Trees are the only structure we have for trees. Treegrids are tables 
>> with twisties, not a tree. Here are some examples of treegrids (from 
>> googling treegrid).
>> http://www.treegrid.com/Grid
>> http://dev.sencha.com/deploy/ext-4.0.1/examples/tree/treegrid.html
>> http://maxazan.github.io/jquery-treegrid/
>> https://dojotoolkit.org/reference-guide/1.10/dojox/grid/TreeGrid.html#dojox-grid-treegrid
>>
>> If I need a tree of widgets (and I don't want them laid out like a 
>> table) what do I use?
>>
>> Regards,
>>
>> Fred Esch
>> Watson, IBM, W3C Accessibility
>> <0E748335.gif> 	Watson Release Management and Quality
>>
>>
>>
>> <graycol.gif>Matt King ---05/25/2016 09:54:21 PM---James, I tested a 
>> listbox with 2 options, each option containing a link, a heading, a 
>> paragraph, and
>>
>> From:Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>>
>> To:"'Bryan Garaventa'" <bryan.garaventa@ssbbartgroup.com 
>> <mailto:bryan.garaventa@ssbbartgroup.com>>, "'James Nurthen'" 
>> <james.nurthen@oracle.com <mailto:james.nurthen@oracle.com>>, 
>> <public-aria-admin@w3.org <mailto:public-aria-admin@w3.org>>
>> Cc:"'Rich Schwerdtfeger'" <richschwer@gmail.com 
>> <mailto:richschwer@gmail.com>>, Fred Esch/Arlington/IBM@IBMUS
>> Date:05/25/2016 09:54 PM
>> Subject:RE: 48 hour Call For Consensus regarding Resolutions from the 
>> May 19, 2016 ARIA Working Group meeting
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> James, I tested a listbox with 2 options, each option containing a 
>> link, a heading, a paragraph, and a toolbar with 2 buttons.
>>
>> I tested in Firefox, IE, Chrome, and Safari with JAWS, NVDA, and 
>> VoiceOver.
>>
>> We have about 80+% presentational implementation. The 20% that is not 
>> presentational is a screen reader disaster. Test result details below.
>>
>> No one should consider putting semantic elements inside options or 
>> treeitems and expect them to be presented as anything other than 
>> text, even if focus moves inside the option. And moving focus inside 
>> an option is an author error because option is not a composite and 
>> the allowed content for option is text.
>>
>> By design, chilcren of options and treeitems are already 
>> presentational. This is how ARIA 1.0 set them up. And, we should 
>> finish the job so we can clean up the 20% mess.
>>
>> The good news is, that if you do a 1/1 switch out to grid roles, it 
>> works on all platforms in all browsers. Screen readers that do 
>> automatic mode switching don’t yet switch modes exactly right all the 
>> time, but we can get that fixed. So, we have a robust solution for 
>> the use cases that James and Fred have raised.
>>
>> In the long term, I would not support changing treeitem and option to 
>> composites. That could really mess up their current use cases. If 
>> people are somehow not satisfied with the grid approaches, which do 
>> work very well, I would instead propose that we add listview and 
>> treeview roles that have composite child elements. That way, the 
>> screen readers will be able to render them in a manner completely 
>> different from listbox and tree-- more like grid and treegrid.
>>
>> Test Results:
>>
>> Chrom/Mac/VO:
>> When reading, no semantics revealed. When interacting with the 
>> option, the text is readable but it is stringified.
>> When tabbing to contained link and buttons: No semantics revealed. 
>> Focusable elements are silent. The ffirst time focus enters the 
>> option, the entire option is read instead of the label of the focused 
>> element. Current focus reports the text of the option for all 
>> contained elements.
>>
>> Safari/Mac/VO:
>> When reading, no semantics revealed. When interacting with the 
>> option, the text is not present.
>> When tabbing to contained link and buttons: No semantics revealed. 
>> Focusable elements are silent. The ffirst time focus enters the 
>> option, the entire option is read instead of the label of the focused 
>> element. Current focus reports the text of the option for all 
>> contained elements.
>>
>> Chrome/Win/JAWS/NVDA:
>> When reading, no semantics revealed. Stringified text of the selected 
>> option is revealed. Selected state is revealed.
>> When tabbing to contained link and buttons: No semantics revealed. 
>> Focusable elements are silent. The ffirst time focus enters the 
>> option, the entire option is read instead of the label of the focused 
>> element. Current focus reports the text of the option for all 
>> contained elements.
>>
>> Firefox/Win/JAWS:
>> When reading before listbox has contained focus, The link, heading , 
>> and paragraph text are stringified for the selected option and the 
>> selected state is revealed. The button labels are omitted.
>> When reading after listbox has contained focus, sometimes it is 
>> different: the link is revealed as a link. The heading and paragraph 
>> are stringified on a separate line. The select state is revealed. The 
>> button labels are omitted.
>> When tabbing to the link and buttons, The link is read as a link but 
>> its label is replaced with the listbox label. The buttons are read as 
>> buttons.
>>
>> Firefox/Win/NVDA:
>> When reading in document review, nothing is read; NVDA just says list.
>> When reading in object review, it is possible to dig into the 
>> document hierarchy and find the semantic elements.
>> When tabbing to the link and buttons: the elements are read with 
>> their labels and roles, but the listbox context is not announced.
>>
>> IE/JAWS:
>> when reading, the link, heading, and paragraph are stringified, but 
>> the toolbar is revealed normally except that the buttons are read 
>> with “listbox item selected” at the beginning of each label.
>> When tabbing to the link and buttons, The link is read as a link but 
>> its label is replaced with the listbox label. The buttons are read as 
>> buttons.
>>
>> IE/NVDA: none of the ARIA is recognized; read as HTML.
>>
>> Except for the odd Firefox behavior, which is technically a bug, This 
>> all makes sense. Given the mappings, it is exactly how it should be.
>>
>> Matt
>>
>> *From:*Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]*
>> Sent:*Wednesday, May 25, 2016 3:04 PM*
>> To:*James Nurthen <james.nurthen@oracle.com 
>> <mailto:james.nurthen@oracle.com>>; Matt King <a11ythinker@gmail.com 
>> <mailto:a11ythinker@gmail.com>>; public-aria-admin@w3.org 
>> <mailto:public-aria-admin@w3.org>*
>> Cc:*'Rich Schwerdtfeger' <richschwer@gmail.com 
>> <mailto:richschwer@gmail.com>>; 'Fred Esch' <fesch@us.ibm.com 
>> <mailto:fesch@us.ibm.com>>*
>> Subject:*RE: 48 hour Call For Consensus regarding Resolutions from 
>> the May 19, 2016 ARIA Working Group meeting
>>
>> By this logic, it is also acceptable to put sliders inside of 
>> role=option nodes too, as well as tablist containers with dynamic 
>> tabs, radio buttons, links, checkboxes, trees, nested Listboxes, and 
>> comboboxes. And yes, I’ve seen developers do these things.
>>
>> The option role is not a composite widget, this is what it says in 
>> the spec. It does not support focusable children.
>>
>> So why is this acceptable or desirable when it goes against the spec 
>> and it causes unlimited accessibility issues?
>>
>>
>> Bryan Garaventa
>> Accessibility Fellow
>> SSB BART Group, Inc.
>> _bryan.garaventa@ssbbartgroup.com_ 
>> <mailto:bryan.garaventa@ssbbartgroup.com>
>> 415.624.2709 (o)
>> _www.SSBBartGroup.com_ <http://www.ssbbartgroup.com/>
>>
>> *From:*James Nurthen [_mailto:james.nurthen@oracle.com_]*
>> Sent:*Wednesday, May 25, 2016 12:41 PM*
>> To:*Bryan Garaventa <_bryan.garaventa@ssbbartgroup.com_ 
>> <mailto:bryan.garaventa@ssbbartgroup.com>>; Matt King 
>> <_a11ythinker@gmail.com_ 
>> <mailto:a11ythinker@gmail.com>>;_public-aria-admin@w3.org_ 
>> <mailto:public-aria-admin@w3.org>*
>> Cc:*'Rich Schwerdtfeger' <_richschwer@gmail.com_ 
>> <mailto:richschwer@gmail.com>>; 'Fred Esch' <_fesch@us.ibm.com_ 
>> <mailto:fesch@us.ibm.com>>*
>> Subject:*Re: 48 hour Call For Consensus regarding Resolutions from 
>> the May 19, 2016 ARIA Working Group meeting
>>
>> I disagree that this is how they currently work.
>>
>> Currently all the child nodes of option are exposed into the 
>> accessibility tree so, if navigation is allowed to them (via a 
>> keyboard switch for example), it is still possible for their correct 
>> role/state information to be accessed by AT.
>>
>> I fear that adding children are presentational to option will 
>> encorage browsers to remove these nodes from the accessibility tree 
>> which will break all kinds of things. Can someone clarify if child 
>> nodes of something with children presenational = true would still be 
>> in the accessibility tree as they are today? If these children are 
>> not in the accessibility tree then I object to this change in ARIA 
>> 1.1. I am happy to revisit it in the ARIA 2.0 timeline.
>>
>> Regards,
>>
>> James
>>
>> On 5/25/2016 12:16 PM, Bryan Garaventa wrote:
>>
>>         +1
>>
>>         I am in favor of leaving role=option and role=treeitem in
>>         this list for the same reasons that Matt outlined here. This
>>         is literally how they already work in ATs and in browsers, so
>>         the change is editorial.
>>
>>         If some want to expand role=option and/or role=treeitem in
>>         the future to be composite, then that could be a 2.0 proposal.
>>
>>
>>         Bryan Garaventa
>>         Accessibility Fellow
>>         SSB BART Group, Inc.
>>         _bryan.garaventa@ssbbartgroup.com_
>>         <mailto:bryan.garaventa@ssbbartgroup.com>
>>         415.624.2709 (o)
>>         _www.SSBBartGroup.com_ <http://www.ssbbartgroup.com/>
>>
>>         *From:*Matt King [_mailto:a11ythinker@gmail.com_]*
>>         Sent:*Tuesday, May 24, 2016 4:25 PM*
>>         To:*Bryan Garaventa_<bryan.garaventa@ssbbartgroup.com>_
>>         <mailto:bryan.garaventa@ssbbartgroup.com>; 'James
>>         Nurthen'_<james.nurthen@oracle.com>_
>>         <mailto:james.nurthen@oracle.com>;_public-aria-admin@w3.org_
>>         <mailto:public-aria-admin@w3.org>*
>>         Cc:*'Rich Schwerdtfeger'_<richschwer@gmail.com>_
>>         <mailto:richschwer@gmail.com>; 'Fred
>>         Esch'_<fesch@us.ibm.com>_ <mailto:fesch@us.ibm.com>*
>>         Subject:*RE: 48 hour Call For Consensus regarding Resolutions
>>         from the May 19, 2016 ARIA Working Group meeting
>>
>>         Fred, Rich, and James,
>>
>>         In practice, the children of option and treeitem elements
>>         already behave as if they are presentational. This is true
>>         for all roles mapped as inputs except composite inputs and
>>         text inputs. However, composite widgets are mapped to desktop
>>         GUI components that have well-defined interaction models and
>>         text inputs have their own special accessible text interface
>>         for rendering the attributes of their content to assistive
>>         technologies.
>>                 ·Options and treeitems are defined in ARIA as
>>                 singular input elements. In this way, they are like
>>                 the other subclasses of input that are not also
>>                 composite or text, i.e., checkbox, radio, slider, and
>>                 spinbutton.
>>                 ·ARIA maps options and treeitems to desktop GUI
>>                 components that do not have either semantic or
>>                 interactive children.
>>                 ·Because of the option and treeitem mappings, most
>>                 assistive technologies do not provide reading modes
>>                 that work inside of option and treitem elements. They
>>                 may provide ways of extracting the text, but it is
>>                 stringafied.
>>                 ·There are no standardized interaction models for
>>                 interacting with content inside of an option or
>>                 treeitem. Assistive tehcnologies can not provide
>>                 guidance to users if focus moves inside of an option
>>                 or treeitem like they can if it moves inside a
>>                 composite or dialog. 
>>         Because option and treeitem have the above attributes but are
>>         not formally defined as children presentational true, there
>>         is confusion about what assistive technologies are capable of
>>         doing with them, how checkers should treat them, and
>>         consequently, what authors should be allowed to do with them.
>>
>>         Net: assistive technologies treat option and treeitem the way
>>         they do in desktop GUIs because that is how they are mapped.
>>         Because of that, all content inside is effectively
>>         presentational. Changing that would mean huge changes to ARIA.
>>
>>         Accepting the proposal as written would bring the spec into
>>         line with current real-world behaviors and limitations. It
>>         will enable us to start fixing problems caused by this confusion.
>>
>>         One of the problems we can fix right away is helping Fred and
>>         James make their UIs accessible within the practical
>>         constraints of ARIA 1.1.
>>
>>         Please, let’s not continue to compound the problems we
>>         already have by removing option and treeitem from this CFC.
>>         Including them is extremely valuable to the clarity,
>>         consistency, and robustness of both the specification and the
>>         authoring practices.
>>
>>         BTW, Fred, one of the reasons I worked so hard on issue 633
>>         to get more flexibility and clarity for grid and dialog is to
>>         make reliable accessibility feasible for the types of UIs you
>>         described. I think we have the tools we need. They may not
>>         be100% optimal, and they fall short of what I originally
>>         envisioned, but they are a good step forward for a 1.1
>>         release of the spec.
>>
>>         Matt King
>>
>>         *From:*Bryan Garaventa
>>         [_mailto:bryan.garaventa@ssbbartgroup.com_]*
>>         Sent:*Tuesday, May 24, 2016 12:14 PM*
>>         To:*James Nurthen <_james.nurthen@oracle.com_
>>         <mailto:james.nurthen@oracle.com>>;_public-aria-admin@w3.org_
>>         <mailto:public-aria-admin@w3.org>*
>>         Subject:*RE: 48 hour Call For Consensus regarding Resolutions
>>         from the May 19, 2016 ARIA Working Group meeting
>>
>>         Can you point to an example of this?
>>
>>         This type of implementation causes so many accessibility
>>         issues in JAWS and NVDA and everywhere else that I’ve tested
>>         that I flag this as a must-fix author error every time I come
>>         across it.
>>
>>         I can’t think of an instance where this is a good idea,
>>         because this maps to the same role type as the HTML option
>>         element.
>>
>>
>>         Bryan Garaventa
>>         Accessibility Fellow
>>         SSB BART Group, Inc.
>>         _bryan.garaventa@ssbbartgroup.com_
>>         <mailto:bryan.garaventa@ssbbartgroup.com>
>>         415.624.2709 (o)
>>         _www.SSBBartGroup.com_ <http://www.ssbbartgroup.com/>
>>
>>         *From:*James Nurthen [_mailto:james.nurthen@oracle.com_]*
>>         Sent:*Tuesday, May 24, 2016 12:02 PM*
>>         To:*_public-aria-admin@w3.org_ <mailto:public-aria-admin@w3.org>*
>>         Subject:*Re: 48 hour Call For Consensus regarding Resolutions
>>         from the May 19, 2016 ARIA Working Group meeting
>>
>>         I object to option being in this list too (for similar
>>         reasons to treeitem).
>>
>>         We currently allow people to jump in and out of an
>>         "interaction" mode in order to allow them to interact with
>>         the child elements. If children presentational is added AT
>>         users will lose that ability.
>>
>>         Regards,
>>
>>         james
>>
>>         On 5/24/2016 10:47 AM, Bryan Garaventa wrote:
>>
>>                 That’s fine with me, though I think we will need to
>>                 have a different proposal to deal with role=treeitem
>>                 separately.
>>
>>                 The problem being that currently no embedded controls
>>                 within treeitems are accessible, since the role=tree
>>                 widget is treated as one form field.
>>                 E.G
>>                 _http://whatsock.com/tsg/Coding%20Arena/ARIA%20Trees/Tree%20(External%20XML)/demo.htm_
>>                 <http://whatsock.com/tsg/Coding%20Arena/ARIA%20Trees/Tree%20%28External%20XML%29/demo.htm>
>>                 (Reproduceable in Firefox using JAWS and NVDA)
>>
>>                 And it’s not clear how anything that is embedded
>>                 within such controls should be discoverable or even
>>                 intuitively interacted with.
>>
>>
>>
>>                 Bryan Garaventa
>>                 Accessibility Fellow
>>                 SSB BART Group, Inc.
>>                 _bryan.garaventa@ssbbartgroup.com_
>>                 <mailto:bryan.garaventa@ssbbartgroup.com>
>>                 415.624.2709 (o)
>>                 _www.SSBBartGroup.com_ <http://www.ssbbartgroup.com/>
>>
>>                 *From:*Rich Schwerdtfeger
>>                 [_mailto:richschwer@gmail.com_]*
>>                 Sent:*Tuesday, May 24, 2016 9:47 AM*
>>                 To:*Bryan
>>                 Garaventa_<bryan.garaventa@ssbbartgroup.com>_
>>                 <mailto:bryan.garaventa@ssbbartgroup.com>*
>>                 Cc:*Fred Esch_<fesch@us.ibm.com>_
>>                 <mailto:fesch@us.ibm.com>; ARIA Working
>>                 Group_<public-aria-admin@w3.org>_
>>                 <mailto:public-aria-admin@w3.org>*
>>                 Subject:*Re: 48 hour Call For Consensus regarding
>>                 Resolutions from the May 19, 2016 ARIA Working Group
>>                 meeting
>>
>>                 I agree. I sent out what was resolved at the meeting
>>                 and had the same thoughts but I was not on the call
>>                 and was going to raise the same exception. We will
>>                 have the same issues we have with options and lists.
>>
>>                 +1 to keeping the proposal minus treeitem.
>>
>>                 Rich
>>
>>
>>
>>                 Rich Schwerdtfeger
>>
>>
>>                         On May 24, 2016, at 10:53 AM, Bryan Garaventa
>>                         <_bryan.garaventa@ssbbartgroup.com_
>>                         <mailto:bryan.garaventa@ssbbartgroup.com>> wrote:
>>
>>                         Currently role=treeitem is not a composite
>>                         widget, and as such nothing rendered within
>>                         these containers is accessible. So not
>>                         including role=treeitem in this list will not
>>                         solve this problem.
>>
>>
>>                         Bryan Garaventa
>>                         Accessibility Fellow
>>                         SSB BART Group, Inc.
>>                         _bryan.garaventa@ssbbartgroup.com_
>>                         <mailto:bryan.garaventa@ssbbartgroup.com>
>>                         415.624.2709 (o)
>>                         _www.SSBBartGroup.com_
>>                         <http://www.ssbbartgroup.com/>
>>
>>                         *From:*Fred Esch [_mailto:fesch@us.ibm.com_]*
>>                         Sent:*Tuesday, May 24, 2016 4:21 AM*
>>                         To:*Rich Schwerdtfeger
>>                         <_richschwer@gmail.com_
>>                         <mailto:richschwer@gmail.com>>*
>>                         Cc:*ARIA Working Group
>>                         <_public-aria-admin@w3.org_
>>                         <mailto:public-aria-admin@w3.org>>*
>>                         Subject:*Re: 48 hour Call For Consensus
>>                         regarding Resolutions from the May 19, 2016
>>                         ARIA Working Group meeting
>>
>>                         Rich,
>>
>>                         I would like to see treeitem dropped from the
>>                         list. No one wants to use treegrid and we see
>>                         UIs with trees of complex widgets which
>>                         should naturally use tree style navigation
>>                         between the them. If we include treeitem in
>>                         the list then you would not be able to call
>>                         something a tree, that looks like a tree and
>>                         you want it to navigate like a tree, if the
>>                         leaves were complex controls that a user
>>                         could choose to leave visible. Again, no one
>>                         will ever call a tree of complex widgets a
>>                         treegrid when where there is no concept of
>>                         rows in the layout.
>>
>>                         Suggested solutions for a tree that are
>>                         compatible with treeitem only having
>>                         presentational children are work arounds such
>>                         as having the widget appear in a dialog when
>>                         you click the treeitem. These 'solutions' are
>>                         not be practical when you have flows, card
>>                         layouts, or block chains that have branching.
>>                         We are seeing lots of card layouts, block
>>                         chains and relationships expressed in web
>>                         apps that would be negatively impacted by
>>                         this restriction. 
>>
>> Regards,
>>
>> Fred Esch
>> Watson, IBM, W3C Accessibility
>> <image001.png> 	Watson Release Management and Quality
>>
>>
>>
>>                         <image002.gif>Rich Schwerdtfeger
>>                         ---05/23/2016 04:06:45 PM---This is a Call
>>                         for Consensus (CfC) to the Accessible Rich
>>                         Internet Applications (ARIA) Working Group
>>
>>                         From:Rich Schwerdtfeger
>>                         <_richschwer@gmail.com_
>>                         <mailto:richschwer@gmail.com>>
>>                         To:ARIA Working Group
>>                         <_public-aria-admin@w3.org_
>>                         <mailto:public-aria-admin@w3.org>>
>>                         Date:05/23/2016 04:06 PM
>>                         Subject:48 hour Call For Consensus regarding
>>                         Resolutions from the May 19, 2016 ARIA
>>                         Working Group meeting
>>                         ------------------------------------------------------------------------
>>
>>
>>
>>
>>                         This is a Call for Consensus (CfC) to the
>>                         Accessible Rich Internet Applications (ARIA)
>>                         Working Group regarding the following
>>                         resolutions of the ARIA Working group.
>>
>>                         1. Add children presentational true to
>>                         checkbox, menuitem, menuitemcheckbox,
>>                         menuitemradio, option, radio, spinbutton,
>>                         switch, tab, and treeitem in response to
>>                         Issue 1006
>>                         The meeting minutes are
>>                         here:_https://www.w3.org/2016/05/19-aria-minutes.html_
>>
>>                         If you object to this proposal, or have
>>                         comments concerning it, please respond by
>>                         replying on list to this message no later
>>                         than 23:49 (midnight) Boston Time, Wednesday,
>>                         May 25, 2016.
>>
>>                         Regards,
>>
>>                         Rich
>>
>>                         —
>>                         Rich Schwerdtfeger,
>>                         Email:_richschwer@gmail.com_
>>                         <mailto:richschwer@gmail.com>
>>                         CTO Accessibility IBM
>>                         Software:_http://www.ibm.com.able_
>>                         <http://www.ibm.com.able/>
>>
>>                         The World Wide Web Consortium (W3C), Web
>>                         Accessibility Initiative (WAI)
>>                         Chair, Accessible Rich Internet
>>                         Applications_https://www.w3.org/WAI/ARIA_
>>
>>                         Rich Schwerdtfeger
>>
>>
>>
>>
>>
>>
>>         --
>>         Regards, James
>>
>>         <0E203729.gif> <http://www.oracle.com/>
>>         James Nurthen | Principal Engineer, Accessibility
>>         Phone:_+1 650 506 6781_ <tel:+1%20650%20506%206781>|
>>         Mobile:_+1 415 987 1918_ <tel:+1%20415%20987%201918>|
>>         Video:_james.nurthen@oracle.com_
>>         <mailto:james.nurthen@oracle.com>
>>         OracleCorporate Architecture
>>         500 Oracle Parkway | Redwood Cty, CA 94065_
>>         _<0E211030.gif> <http://www.oracle.com/commitment>Oracle is
>>         committed to developing practices and products that help
>>         protect the environment
>>
>>
>> --
>> Regards, James
>>
>> <0E203729.gif> <http://www.oracle.com/>
>> James Nurthen | Principal Engineer, Accessibility
>> Phone:_+1 650 506 6781_ <tel:+1%20650%20506%206781>| Mobile:_+1 415 
>> 987 1918_ <tel:+1%20415%20987%201918>| 
>> Video:_james.nurthen@oracle.com_ <mailto:james.nurthen@oracle.com>
>> OracleCorporate Architecture
>> 500 Oracle Parkway | Redwood Cty, CA 94065_
>> _<0E211030.gif> <http://www.oracle.com/commitment>Oracle is committed 
>> to developing practices and products that help protect the environment
>>
>>
>>
>>
>

-- 
Regards, James

Oracle <http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 
1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com 
<sip:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment
Received on Thursday, 26 May 2016 16:35:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:27 UTC