- From: Fred Esch <fesch@us.ibm.com>
- Date: Tue, 31 May 2016 10:00:12 -0400
- To: James Nurthen <james.nurthen@oracle.com>
- Cc: public-aria@w3.org
- Message-Id: <20160531140052.89538BE05B@b03ledav005.gho.boulder.ibm.com>
+1
Providing an attribute to tell whether an element is presentational or not
is a good idea. It is better to have user agents handle complexity rather
than have scripts and authors handle complexity. User agent behavior will
be tested. Toggling a property on an element that's content changes is much
easier on a author and script than finding the tree root and changing a
treeful of roles when the content of one leaf in the tree changes. For
authors and scripts the alternative would be to always use the roles for
interactive content even when the content is presentational. ARIA should
not be a burden for authors and scripts.
Regards,
Fred Esch
Watson, IBM, W3C
Accessibility
IBM Watson Watson Release Management and Quality
From: James Nurthen <james.nurthen@oracle.com>
To: public-aria@w3.org
Date: 05/27/2016 06:54 PM
Subject: Re: 48 hour Call For Consensus regarding Resolutions from the
May 19, 2016 ARIA Working Group meeting
As I said previously - in the implementation there was a help message to
tell the user what to do to interact with the option. It certainly would
not be intuitive without that.
IMO if we want to go down this path in the ARIA 2.0 timeframe an attribute
on an element to tell a user they can interact with its children would be a
good path forward. If a user chose to do this then they would essentially
end up in a modal where they interact only with the children of that
element until they choose to escape out of that. This could (theoretically)
support multiple levels of this type of interaction, although in practice
this could end up being pretty painful to use.
Regards,
James
On 5/27/2016 3:35 PM, Birkir Gunnarsson wrote:
The <option> element’s default implicit ARIA semantic is
role=”option” according to http://www.w3.org/TR/html-aria/
HTML does not allow focusable elements inside the option element.
If we are to start allowing focusable elements inside ARIA option
role we either have to:
· Change the mapping of the HTML option element to a
different ARIA role (if so, what)?
Or
· Make the ARIA option role different (i.e., creat a new
role), or tell user that it is different from the HTML option
tag (create a new attribute).
We recently defended ARIA tabs in an article exchange by explaining
that users use affordance to interact with elements they are familiar
with.
Applying that logic to this situation, if I am in a listbox on a
webpage and I hear my screen reader say “option” I fall back on my
years of interaction with options on webpages, which has taught me
that the only thing you can do with them is navigate between them, or
use keyboard shortcuts to select and de-select them.
From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Friday, May 27, 2016 4:05 PM
To: 'Bryan Garaventa' <bryan.garaventa@ssbbartgroup.com>; 'Schnabel,
Stefan' <stefan.schnabel@sap.com>; 'Rich Schwerdtfeger'
<richschwer@gmail.com>
Cc: 'Fred Esch' <fesch@us.ibm.com>; public-aria-admin@w3.org;
'Accessible Rich Internet Applications Working Group'
<public-aria@w3.org>
Subject: RE: 48 hour Call For Consensus regarding Resolutions from
the May 19, 2016 ARIA Working Group meeting
Stefan,
The fact that ARIA does not support nesting focusable elements and
semantic structures inside treeitem and option elements is not a
showstopper. We can still make the UIs you have described accessible.
Earlier in the 1.1 cycle, with this problem in mind, we made changes
to the grid description, that are also inherited by treegrid, that
help in the situations you describe. In some cases, it is as simple
as a 1/1 swap of grid for listbox and gridcell for option, putting
row on an intervening element, and you are done. However, if you had
wanted to include multiple focusable elements in an option, you can
make a simpler interaction model if you break the option into a row
with multiple gridcells.
I commited the APG task force to addressing these patterns, with
examples, in the next 8 weeks. It is a priority for us to have
reference implementations, especially so screen reader developers
have a resource for ironing out glitches. There are definitely some
issues with screen reader support for treegrid.
Those are glitches we can resolve. The lack of accessibility that you
get when putting focusable elements and semantic structures inside
options and treeitems are problems that we can not resolve because,
as Bryan so well described, they are not accessible by definition.
We moved the CFC forward, including treeitem and option, in light of
the constraints ARIA has already placed on them, with an
understanding of the way that browsers and assistive technologies
render them, and with the knowledge that we have ways of addressing
the needs that you expressed.
The APg TF will share examples as soon as we have them available and
solicit feedback to ensure we have addressed the needs that people
have.
Matt
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Friday, May 27, 2016 10:38 AM
To: Schnabel, Stefan <stefan.schnabel@sap.com>; Rich Schwerdtfeger
<richschwer@gmail.com>
Cc: Fred Esch <fesch@us.ibm.com>; Matt King <a11ythinker@gmail.com>;
public-aria-admin@w3.org; Accessible Rich Internet Applications
Working Group <public-aria@w3.org>
Subject: RE: 48 hour Call For Consensus regarding Resolutions from
the May 19, 2016 ARIA Working Group meeting
“True. Options MAY contain interactive subelements such as two
different links. This is the reason why ARIA and keyboard support by
JS must always go together in patterns.
Same as for tree nodes.
Simply forbidding it is not the solution since developers do this as
result of interaction designs that have often good reasons to be as
such.”
Actually no, because this is not supported in the ARIA spec. If
developers do something that goes against what is documented in the
ARIA specification, it should be no surprise that it results in
inaccessible software when used by people who require the use of
assistive technologies.
If the desire is to do something like this, then the rules cannot
just be changed on the fly like this, but it needs to be put into the
specification so that user agents and assistive technologies can
properly support it. Otherwise, this practice results in inaccessible
software.
By the way, Rich agreed yesturday during the call as did we all that
this change should go forward, and that we should work on the role of
treegrid with user agent and AT support to ensure this is working for
the embedding of active elements because this role with gridcell is a
composite.
At present role=option and role=treeitem cannot support focusable
children as active elements accessibly, because neither of these
roles is composite according to the spec.
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
www.SSBBartGroup.com
From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com]
Sent: Thursday, May 26, 2016 11:34 PM
To: Rich Schwerdtfeger <richschwer@gmail.com>
Cc: Fred Esch <fesch@us.ibm.com>; Matt King <a11ythinker@gmail.com>;
public-aria-admin@w3.org; Accessible Rich Internet Applications
Working Group <public-aria@w3.org>
Subject: Re: 48 hour Call For Consensus regarding Resolutions from
the May 19, 2016 ARIA Working Group meeting
Sorry, I don’t buy the arguments requiring the descendants to
be presentational.
True. Options MAY contain interactive subelements such as two
different links. This is the reason why ARIA and keyboard support by
JS must always go together in patterns.
Same as for tree nodes.
Simply forbidding it is not the solution since developers do this as
result of interaction designs that have often good reasons to be as
such.
Instead, a standard keyboard navigation pattern has to be defined to
access the inner content in such cases.
For instance, an ARIA grid cell is focusable and contains 2
interactive but readonly elements (same story).
We defined arrow navigation between grid cells. Entering cells
requires TAB that does not leave the grid but will focus the first
cell element inside, next Tab second element. Coming back on cell
level by shift+tab as reverse action. From there, arrowing again, and
so on. This requires of course context-aware JS keyboard code,
knowing that focus is Inside a cell or ON a cell. More complicated
but doable.
Regards
Stefan
Sent from my iPad
On 26.05.2016, at 17:46, Rich Schwerdtfeger <richschwer@gmail.com>
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>
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>
To: "'Bryan Garaventa'" <
bryan.garaventa@ssbbartgroup.com>, "'James Nurthen'" <
james.nurthen@oracle.com>, <public-aria-admin@w3.org>
Cc: "'Rich Schwerdtfeger'" <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>; Matt King <
a11ythinker@gmail.com>; public-aria-admin@w3.org
Cc: 'Rich Schwerdtfeger' <richschwer@gmail.com>; 'Fred
Esch' <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
415.624.2709 (o)
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>;
Matt King <a11ythinker@gmail.com>;
public-aria-admin@w3.org
Cc: 'Rich Schwerdtfeger' <richschwer@gmail.com>; 'Fred
Esch' <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
415.624.2709 (o)
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>; 'James
Nurthen' <james.nurthen@oracle.com>;
public-aria-admin@w3.org
Cc: 'Rich Schwerdtfeger'
<richschwer@gmail.com>; 'Fred Esch'
<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
>; 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
415.624.2709 (o)
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
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
(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
415.624.2709 (o)
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>
Cc: Fred Esch <fesch@us.ibm.com>;
ARIA Working Group
<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
> 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
415.624.2709 (o)
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>
Cc: ARIA Working
Group <
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>
To: ARIA Working
Group <
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
CTO Accessibility IBM
Software:
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>
James Nurthen | Principal Engineer,
Accessibility
Phone: +1 650 506 6781 | Mobile: +1 415 987
1918 | Video: james.nurthen@oracle.com
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
<0E211030.gif>Oracle is committed to
developing practices and products that help
protect the environment
--
Regards, James
<0E203729.gif>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 | Mobile: +1 415 987 1918 |
Video: james.nurthen@oracle.com
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
<0E211030.gif>Oracle is committed to developing practices
and products that help protect the environment
--
Regards, James
Oracle
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 | Mobile: +1 415 987 1918 | Video:
james.nurthen@oracle.com
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
Green
OracleOracle is committed to developing practices and
products that help protect the environment
Attachments
- image/gif attachment: 08050957.gif
- image/gif attachment: graycol.gif
- image/gif attachment: 08286948.gif
- image/gif attachment: 08923696.gif
Received on Tuesday, 31 May 2016 14:01:59 UTC