Evaluating accessibility compliance of a hybrid user interface design

TECHNICAL FIELD

0001The present invention relates generally to a method, system, and computer program product for evaluating the user interfaces used on computing devices. More particularly, the present invention relates to a method, system, and computer program product for evaluating accessibility compliance of a hybrid user interface design.

BACKGROUND

0002Almost all data processing systems, including mobile devices, include some manner of interacting with a user. For example, a display device is used with a data processing system for presenting a visual user interface to a user, an audio device is used with the data processing system for presenting audible user interface to the user, and tactile devices are used for presenting a tactile interface to the user. Within the scope of the disclosure, the term “user interface” refers to a user interface of any of these types or other types as may be suitable for a particular implementation.

0003Accessibility features are features of a user interface that are designed or configured to assist a user in interacting with a particular aspect of a given user interface. For example, a large default font size is an example accessibility feature that makes interacting with a user interface easier for those users who have weak eyesight. Similarly, an audio readout accessibility feature assists users with vision impairment to interact with a user interface. A tactile feedback, such as vibration of a mobile device, is another example accessibility feature for users who have temporary, circumstantial, or permanent auditory impairment. Such features benefit users experiencing impairments, whether temporary, circumstantial, preferential, or permanent.

0004Many accessibility features are presently available for use in user interface designs. Often, an application executing on a data processing system presents several user interfaces to the user during the course of using the application. For example, numerous user interfaces in the forms of screen layouts, plugin applications, and tools are presented or called upon during the course of a user using a software application.

SUMMARY

0005The illustrative embodiments provide a method, system, and computer program product for evaluating accessibility compliance of a hybrid user interface design. An embodiment includes a method for evaluating compliance of a hybrid user interface design. The embodiment receives, from a first application executing in a client data processing system, a first hierarchy of a first type of elements of a user interface, wherein a second application presents the user interface including a set of the first type of elements and a set of a second type of elements at the client data processing system. The embodiment receives, from the first application, a second hierarchy of the second type of elements used in a system-specific presentation of the user interface at the client data processing system. The embodiment determines that a first element of the first type in the first hierarchy violates a condition specified in a compliance rule. The embodiment determines that a second element of the second type in the second hierarchy is related to the first element. The embodiment evaluates that an attribute of the second element causes the condition to be violated. The embodiment reports, responsive to the evaluating, the second element as the cause of violating the condition.

0006Another embodiment includes a computer usable program product comprising a computer readable storage device including computer usable code for evaluating compliance of a hybrid user interface design. The embodiment further includes computer usable code for receiving, from a first application executing in a client data processing system, a first hierarchy of a first type of elements of a user interface, wherein a second application presents the user interface including a set of the first type of elements and a set of a second type of elements at the client data processing system. The embodiment further includes computer usable code for receiving, from the first application, a second hierarchy of the second type of elements used in a system-specific presentation of the user interface at the client data processing system. The embodiment further includes computer usable code for determining that a first element of the first type in the first hierarchy violates a condition specified in a compliance rule. The embodiment further includes computer usable code for determining that a second element of the second type in the second hierarchy is related to the first element. The embodiment further includes computer usable code for evaluating that an attribute of the second element causes the condition to be violated. The embodiment further includes computer usable code for reporting, responsive to the evaluating, the second element as the cause of violating the condition.

0007Another embodiment includes a data processing system for evaluating compliance of a hybrid user interface design. The embodiment further includes a storage device, wherein the storage device stores computer usable program code. The embodiment further includes a processor, wherein the processor executes the computer usable program code. The embodiment further includes computer usable code for receiving, from a first application executing in a client data processing system, a first hierarchy of a first type of elements of a user interface, wherein a second application presents the user interface including a set of the first type of elements and a set of a second type of elements at the client data processing system. The embodiment further includes computer usable code for receiving, from the first application, a second hierarchy of the second type of elements used in a system-specific presentation of the user interface at the client data processing system. The embodiment further includes computer usable code for determining that a first element of the first type in the first hierarchy violates a condition specified in a compliance rule. The embodiment further includes computer usable code for determining that a second element of the second type in the second hierarchy is related to the first element. The embodiment further includes computer usable code for evaluating that an attribute of the second element causes the condition to be violated. The embodiment further includes computer usable code for reporting, responsive to the evaluating, the second element as the cause of violating the condition.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

0008The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of the illustrative embodiments when read in conjunction with the accompanying drawings, wherein:

0009<figref idref="DRAWINGS">FIG. 1</figref> depicts a block diagram of a network of data processing systems in which illustrative embodiments may be implemented;

0010<figref idref="DRAWINGS">FIG. 2</figref> depicts a block diagram of a data processing system in which illustrative embodiments may be implemented;

0011<figref idref="DRAWINGS">FIG. 3</figref> depicts an example configuration for evaluating accessibility compliance of a hybrid user interface design in accordance with an illustrative embodiment;

0012<figref idref="DRAWINGS">FIG. 4</figref> depicts a block diagram of a configuration for evaluating accessibility compliance of a hybrid user interface design in accordance with an illustrative embodiment;

0013<figref idref="DRAWINGS">FIG. 5</figref> depicts a block diagram of an example hybrid UI whose accessibility can be evaluated in accordance with an illustrative embodiment;

0014<figref idref="DRAWINGS">FIG. 6</figref> depicts a process of generating a hierarchy of elements for evaluating accessibility compliance of a UI design in accordance with an illustrative embodiment;

0015<figref idref="DRAWINGS">FIG. 7A</figref> depicts a block diagram of an example way of representing elements of a hybrid UI in accordance with an illustrative embodiment;

0016<figref idref="DRAWINGS">FIG. 7B</figref> depicts a block diagram of another example way of representing elements of a hybrid UI in accordance with an illustrative embodiment;

0017<figref idref="DRAWINGS">FIG. 8</figref> depicts a flowchart of an example process for constructing an accessibility hierarchy in accordance with an illustrative embodiment;

0018<figref idref="DRAWINGS">FIG. 9</figref> depicts a flowchart of an example process for evaluating accessibility compliance of a hybrid UI design in accordance with an illustrative embodiment;

0019<figref idref="DRAWINGS">FIG. 10</figref> depicts an example process for unifying or creating a unified accessibility compliance report in accordance with an illustrative embodiment; and

0020<figref idref="DRAWINGS">FIG. 11</figref> depicts another example process for unifying or creating a unified accessibility compliance report in accordance with an illustrative embodiment.

DETAILED DESCRIPTION

0021Within the scope of this disclosure, the term “accessibility” includes not only the considerations in making a user interface usable despite some disability, but also considerations for improving the usability of a user interface generally. To such end, the term “accessibility” is inclusive of other terms, such as “usability”.

0022An element of a user interface (UI) is a part, portion, or component used in the UI. A UI element is often, but need not necessarily be, visible or perceptible to a user. A UI element has associated therewith a set of one or more attributes. A UI element can depend on or relate to another UI element such that an attribute of the UI element is changed, restricted, overridden, controlled, limited, manipulated, guided, or otherwise affected by an attribute of the related UI element. An accessibility feature of a UI is a result of adding, removing, or modifying one or more elements of the UI, adjusting one or more attributes of the one or more elements of the UI, or a combination thereof.

0023The illustrative embodiments recognize that accessibility features of a UI are largely implementation dependent, and are generally decided by software manufacturers and software developers. Standards and specifications for some accessibility features presently exist, with new accessibility features and their specifications evolving with the advancement of technology.

0024The illustrative embodiments further recognize that a UI is also dependent upon the hardware platform, hardware-software combination, or both, (collectively, hereinafter, “native infrastructure”) on which the UI is to be presented. For example, a UI that is to be presented on a device using iOS™ can, and often does, implement UI elements differently from an implementation of the same UI elements for the Android™ platform (iOS is a trademark of Cisco Systems, Inc. licensed to Apple Inc., and Android is a trademark of Google Inc., in the United States and in other countries).

0025A native widget is any component of a given native infrastructure that contributes, controls, affects a native element, or otherwise causes a native element to be manipulated. A native element is a UI element that is implemented in the native infrastructure, independent of particular UIs that are presented on the given native infrastructure.

0026By comparison, a non-native element is a UI element that is specific to the particular UI that is presented on one or more types of native infrastructures. Only as an example and without implying any limitations thereto on the illustrative embodiments, assume that an example UI is implemented in HyperText Markup Language (HTML, html). A page in the UI is implemented using a variety of html elements, such as the page, forms, tables, buttons, radio-buttons, slider-control, checkboxes, text fields, labels, and the like. An html element such as a table, is coded in html such that relative to other elements on the UI page, the table element is presented in a similar manner when the page is presented on any given native infrastructure.

0027In continuation of the same example, assume that the native infrastructure comprises iOS platform. A native element in that native infrastructure is webView, which implements methods for accessing native resources available in that native infrastructure, e.g., hardware components in the iOS device, software services in the iOS operating system, and the like. The webView native element implements a browser therein, using which UI of web pages can be presented.

0028Many other types of native elements are possible and are contemplated within the scope of the illustrative embodiments. For example, a button artifact on a user interface can be a native element as well, such as a “Home” button, a “start” button, a “back” button, and so on. Slider controls, checkboxes, and other graphical artifacts can be present as native elements, non-native elements, or both, on a user interface in a similar manner.

0029The illustrative embodiments recognize that the manner in which the html elements of a given page are eventually presented on a particular device can be influenced or affected by how the native elements are implemented on that device's native infrastructure. For example, if a native element defines a size or coordinates of a display area, the html table presented within that display area may or may not require scrolling. As another example, if a native element defines a background color, the color scheme of an html element, e.g., a form, may be overridden. As another example, if a native element is a button graphic, an html element that is a different button graphic in webView, when presented using the native infrastructure, may appear closer than a threshold distance from the native button element.

0030Only for the clarity of the description and not to imply any limitation on the illustrative embodiments, hereinafter in the disclosure, operations and features related to non-native elements are interchangeably referred to as web elements. Any reference to a web element or an organization thereof is similarly applicable to other types of non-native elements or organizations thereof within the scope of the illustrative embodiments.

0031Presently, verifying compliance of an accessibility feature with a specification is also dependent upon the participation of the software manufacturer, the software developer, one or more entities involved in the development of a native infrastructure, and/or the user. For example, some software manufacturers include accessibility testing as a part of software testing activity and include an accessibility compliance report generated therefrom with the software. Some other software products are distributed with manufacturer-supplied accessibility testing tools bundled with the software. Some entities test native infrastructure for accessibility compliance or provide testing tools for such testing.

0032The illustrative embodiments recognize that because of such disconnected and diverse ways of testing or checking for accessibility compliance, the presently available methods for accessibility compliance checking are non-uniform across applications. The illustrative embodiments further recognize that the presently available accessibility compliance checking methods are static, to wit, they check for accessibility compliance according to the accessibility compliance rules existing at the time the packaged report or tool was created, according to the accessibility compliance rules controlled by manufacturers or developers, and according to a manner of applying those accessibility compliance rules selected by the manufacturer or developer.

0033Many accessibility features depend on, or are a result of rules. For example, a rule interpreted from a government law, an industrial standard, a usability specification, or industry best practice often forms a basis for an accessibility feature.

0034The illustrative embodiments recognize that many entities can contribute accessibility compliance rules at any given time. For example, different standards bodies can promulgate or recommend different sets of accessibility compliance rules as applicable to different accessibility features, different geographical locales, different devices or technological components involved, government or governing regulations, and many other factors. As another example, an association of interested parties, e.g. an association of software manufacturers, software developers, users, device manufacturers, native infrastructure developers, or public interest groups, can similarly contribute one or more sets of accessibility compliance rules, policies, preferences, guidelines, or recommendations. An accessibility compliance rule, policy, preference, guideline, regulation, recommendation, or specification is collectively referred to herein as an accessibility compliance rule or simply a rule.

0035Furthermore, such sets of rules can be overlapping, can have an order of preference or application, can have different effective periods, can be provided in different forms, and can be differently applicable or not applicable according to circumstances. Additionally, an entity may wish to add supplementary rules, prioritize certain rules, or choose to ignore other rules generally or in certain conditions. Various rule sets may also apply differently depending on device usage, markets, or device capabilities. The illustrative embodiments recognize that the presently available methods of accessibility compliance checking are not conducive to making an on-demand, unbiased, comprehensive, current, and selective accessibility compliance check of a UI.

0036Depending on its nature, an accessibility feature can be statically created on an interface during the design of the interface, or dynamically added to the interface during running of a program on a native infrastructure, a result generated from a program logic, or based on input from a user. Regardless of how created, an accessibility feature has to be tested as a part of testing the overall UI and in the context of other features of the UI, e.g., by testing the effects of the accessibility feature on other native and non-native elements.

0037Testing UIs presently requires laborious manual testing by persons with special training. Not only can such testing methods be expensive, such presently used testing methods frustrate modern coding practices such as Agile and Continuous Delivery, which are designed to take advantage of automated testing methods. Further, while there are compliance checking tools for the HTML-based application which analyze the page using the page structure of the document object model (DOM), the technology doesn't work for the applications that are directly created from a object language (such as C, Objective-C or Java™) in which the source code or compiled binary cannot be directly used for accessibility evaluation. Such presently available technology is also insufficient for checking accessibility compliance dynamically, to wit, as the native platforms change, as the UI is presented on different native infrastructures, or as UI elements are affected during the presentation due to the underlying native infrastructure operations.

0038The illustrative embodiments used to describe the invention generally address and solve the above-described problems and other problems related to accessibility compliance checking of UI features. The illustrative embodiments provide a method, system, and computer program product for evaluating accessibility compliance of a hybrid user interface design.

0039An embodiment constructs one or more hierarchies of elements of a UI dynamically during the running of a program, identifying in the one or more hierarchies any accessibility attributes associated with the elements represented therein. For example, an embodiment constructs one hierarchy for web elements in a given UI. The embodiment constructs another for native elements used by the UI, native elements affecting the web elements in the UI, native elements affected by the web elements of the UI, or some combination thereof.

0040In one embodiment, the construction of a hierarchy is responsive to detecting an event on a data processing system, such as in a native infrastructure. For example, one embodiment detects a launch of an application on a data processing system to identify a UI that is presented as a result of the launch. Another embodiment detects a change of the UI, e.g., a change in the layout or composition of an existing UI resulting from a user action, a system action, a transaction, or a computation. Another embodiment detects a change of the UI due to an update to the HTML page in a webView as a result of running a Java script. Generally, any manner of identifying a UI is response to any type of event is contemplated within the scope of the illustrative embodiments.

0041An embodiment constructs the hierarchy using a description of the UI. For example, an application designed to run on Android platform may use a layout description file in eXtensible Markup Language (XML) that specifies how the interface should appear on the screen of a user device. Such description identifies various native elements and their attributes present in the UI. While some such descriptions may include a web view that can be used to host a hierarchy of the web elements of their own, a hierarchy of web elements for accessibility compliance according to an embodiment is distinct from such hierarchy in the description of the UI. For example, an embodiment constructs a hierarchy of web elements using DOM corresponding to a web page that is loaded, or is to be loaded. DOM and web page are described only as examples without limiting the illustrative embodiments thereto. Other suitable forms of a document that is loaded, or is to be loaded, including the examples of DOM and web pages but not limited thereto, are also usable to provide the information that is usable for constructing a hierarchy of non-native elements in a similar manner.

0042For example, the web view may initially load only a div, a script, and a style element. But during a user interaction, as a result of running a Java script and applying the styles, a hierarchy of a large set of web elements according to an order of use on the UI, are created. The creation may be followed by different accessibility hierarchies being created according to the web UI changes. An accessibility hierarchy according to an embodiment regroups, reclassifies, replicates, or otherwise reorganizes the web elements according to common properties in subsets of the web elements, thereby making the embodiment's hierarchy distinct from the hierarchy of the UI elements. As another example, a hierarchy according to an embodiment omits certain web elements appearing in the hierarchy in the description when those web elements are known or determined to be irrelevant to accessibility features, thereby making the embodiment's hierarchy distinct from the hierarchy of the UI description.

0043As another example, the hierarchy may include a hierarchy of a set of only those web elements that are present in the UI but not the web elements that are resolved, created, or presented as a result of a run-time activity on the UI. A hierarchy according to an embodiment explores such unidentified or run-time web elements, and includes them in the hierarchy, thereby making the embodiment's hierarchy distinct from the hierarchy of the UI description. Some examples of such web elements are controls on an audio or video plugin that is called when the user interacts with audio or video content, and controls or features on a magnification tool or a utility that is activated in response to a user interaction with a control or content on the UI. A hierarchy may include other attributes (such as screen coordinate of a web element) necessary to determine or markup a web element to be included in the accessibility report. A hierarchy may also include calculated attributes for a web element from a hierarchical structure, for example, color contrast for a layered view structures such as a button with a label or an image button.

0044In a similar manner, an embodiment constructs a hierarchy of native elements and their corresponding attributes. For constructing a hierarchy of the native elements an embodiment can use, but is not limited to using, information available or discoverable from the native infrastructure, documentation available from a native infrastructure developer, or a combination of these and other sources. Furthermore, the hierarchy of native elements constructed by an element for accessibility compliance checking purposes is distinct from any express or implied hierarchy of UI elements that may be available from such sources for similar reasons as described above with respect to the hierarchy of web elements.

0045When the disclosure refers to an “element” and not specifically to a “web element”, “non-native element”, or “native element”, that portion of the disclosure is intended to be applicable to non-native element and native element in a similar manner, unless specifically described otherwise in that portion.

0046A container element includes or ‘contains’ other elements. A container element can include one or more other container elements, one or more elements, or a combination thereof. Furthermore, a container element can contribute, change, control, limit, restrict, modify, affect, or otherwise manipulate or cause to be manipulated another element in another hierarchy without containing or including the other element of the other hierarchy. For example, a webView element is a native container element. The webView element also influences the entire hierarchy of web elements of an html UI contained in the webView container, which is presented within the display artifact corresponding to the webView container element on a given native infrastructure.

0047A native container element can include other native elements in a hierarchy of native elements. For example, in some implementations, the webView container element can include other native elements that may be presented relative to other native or non-native elements presented in the UI in the webView.

0048For accessibility compliance checking an embodiment constructs a hierarchy of elements for nested or structured elements of the UI as well. For example, when a UI includes a container element in a parent-child relationship with one or more contained elements, an embodiment traverses such containers to the lowest level contained elements. For insertion into the hierarchy according to an embodiment, the embodiment considers not only the attributes associated with the lowest level contained element but also the attributes available at the element by inheritance from one or more parent container elements of the UI.

0049When cross-hierarchy elements influence each other, such as in the webView container element example above, for an element in a hierarchy, an embodiment further notes the accessibility attributes of the influencing element from the other hierarchy. In one embodiment, such notation of accessibility attributes of the influencing elements is only a reference to the influencing element. In another embodiment, such notation is an inclusion of or a reference to the specific accessibility attributes of the influencing element of the other hierarchy. In another embodiment, such notation further includes a description or indication of a nature or type of relationship between the element of the hierarchy and the influencing element of the other hierarchy.

0050In addition to constructing a hierarchy of web elements, an embodiment further associates a screenshot of the UI with the hierarchy to assist identification, recognition, or markup of a web element in the accessibility hierarchy.

0051Another embodiment receives the hierarchy constructed in any of these manners for evaluating accessibility compliance. In one implementation, such an embodiment is implemented in a server computer and receives the hierarchy from another embodiment executing in a client computer or device. In another implementation, the server computer is a part of a cloud computing environment. In another implementation, the embodiment that receives the hierarchy and performs the compliance evaluation is configured as a service available from a server or a cloud, and usable by a variety of client applications, client devices, client operating systems, and generally any type of client environment.

0052Regardless of how and where implemented, an embodiment can be implemented such that a single instance performs the accessibility compliance checking of a native hierarchy and a non-native hierarchy. Another embodiment can be implemented such that one instance performs the accessibility compliance checking of a native hierarchy and another of a non-native hierarchy.

0053An embodiment for compliance evaluation accesses a set of accessibility compliance rules in a repository. For example, an embodiment evaluating accessibility compliance of a hierarchy of non-native elements (non-native hierarchy) uses a set of accessibility compliance rules that are applicable to the non-native elements, e.g., html elements. Similarly, an embodiment evaluating accessibility compliance of a hierarchy of native elements (native hierarchy) uses a set of accessibility compliance rules that are applicable to the native elements, e.g., elements operating to present a UI in the iOS environment. Furthermore, a repository can store and provide the accessibility compliance rules that are applicable to the non-native elements, the accessibility compliance rules that are applicable to the native elements, or both.

0054Any number of entities can contribute to any number of repositories, any number and types of accessibility compliance rules, at any time, in any combination, and with any restrictions or conditions on their use. The embodiment selects one or more rules according to a user profile, an application profile, a native infrastructure profile, a standard, or a combination thereof.

0055For example, a normalized profile for users with certain disabilities can help select certain rules but not others such that the selected rules test the compliance of the accessibility features relevant to the disability. Similarly, an application profile can select those rules that check for compliance of accessibility features commonly found in applications or native-infrastructures fitting that profile, and not others. Profile-based rule selection is optional in an embodiment to optimize evaluation time, cost, or user-experience.

0056An embodiment determines whether one or more elements in received hierarchy meet, exceed, or fail an accessibility specification according to a selected rule. One embodiment generates an accessibility compliance report that includes reports of elements that fail the compliance evaluation. Another embodiment generates an accessibility compliance report that includes reports of elements that pass the compliance evaluation as well as the elements that fail the compliance evaluation.

0057Another embodiment generates an accessibility compliance report that includes reports of elements that fail the compliance evaluation along with a severity of the failure. For example, non-compliance of one element may be acceptable in a given situation whereas non-compliance of another element may not. In some cases, a warning about the non-compliance of an element may be sufficient, and in other cases, a notification about a possible non-compliance may be warranted. As another example, non-compliance of an element in one attribute of accessibility may indicate one level of severity or consequences whereas non-compliance of an element in another attribute of accessibility, or in more than a threshold number of attributes, may indicate another level of severity or consequences.

0058An embodiment further generates an accessibility compliance report that includes reports of elements that fail the compliance evaluation along with a recommended remedy for curing the failure. For example, an accessibility specification may specify a remedy for a failure condition. An embodiment matches the condition why an element failed accessibility compliance evaluation with such failure condition, and recommends the corresponding remedy in the report.

0059The accessibility compliance evaluation of a non-native hierarchy by an embodiment results in an accessibility compliance report pertaining to the non-native elements in that hierarchy. Similarly, the accessibility compliance evaluation of a native hierarchy by an embodiment results in an accessibility compliance report pertaining to the native elements in that hierarchy.

0060In one embodiment, the compliance report of different hierarchies are generated and presented as separate reports. Such separation of reports is helpful when different developer groups have to work on the compliance of native and non-native elements. In another embodiment, the compliance report of different hierarchies are generated and presented as a unified report. Such a unified report is helpful when a developer attempting to remedy a compliance of a non-native element has to understand the relationship between the non-native element and a native element in the infrastructure where the non-compliance occurs. For example, sometimes the non-compliance of a non-native element has be remedied by changing an attribute of a native element, and without a unified report, such remedies will be cumbersome, error-prone, or even unsatisfactory.

0061A method of an embodiment described herein, when implemented to execute on a data processing system, comprises substantial advancement of the functionality of that data processing system in making UIs accessibility compliant. For example, the illustrative embodiments enable the data processing system to dynamically determine environment-specific, user-specific, accessibility compliance of a UI relative a given native infrastructure. Such manner of accessibility compliance checking is unavailable in presently operating data processing systems that present UIs. Thus, a substantial advancement of such data processing systems by executing a method of an embodiment comprises checking a UI for accessibility compliance without being limited to static compliance testing, manufacturer or developer specified compliance checking, and partial compliance checking of only a piece of the entire environment that contributes to the presentation of the UI.

0062The illustrative embodiments are described with respect to certain accessibility features, UIs, non-native elements, native elements, relationships, attributes, native-infrastructure, hierarchies, profiles, reports, policies, logic, rules, data processing systems, environments, components, and applications only as examples. Any specific manifestations of such artifacts are not intended to be limiting to the invention. Any suitable manifestation of these and other similar artifacts can be selected within the scope of the illustrative embodiments.

0063Furthermore, the illustrative embodiments may be implemented with respect to any type of data, data source, or access to a data source over a data network. Any type of data storage device may provide the data to an embodiment of the invention, either locally at a data processing system or over a data network, within the scope of the invention.

0064The illustrative embodiments are described using specific code, designs, architectures, protocols, layouts, schematics, and tools only as examples and are not limiting to the illustrative embodiments. Furthermore, the illustrative embodiments are described in some instances using particular software, tools, and data processing environments only as an example for the clarity of the description. The illustrative embodiments may be used in conjunction with other comparable or similarly purposed structures, systems, applications, or architectures. An illustrative embodiment may be implemented in hardware, software, or a combination thereof.

0065The examples in this disclosure are used only for the clarity of the description and are not limiting to the illustrative embodiments. Additional data, operations, actions, tasks, activities, and manipulations will be conceivable from this disclosure and the same are contemplated within the scope of the illustrative embodiments.

0066Any advantages listed herein are only examples and are not intended to be limiting to the illustrative embodiments. Additional or different advantages may be realized by specific illustrative embodiments. Furthermore, a particular illustrative embodiment may have some, all, or none of the advantages listed above.

0067With reference to the figures and in particular with reference to <figref idref="DRAWINGS">FIGS. 1 and 2</figref>, these figures are example diagrams of data processing environments in which illustrative embodiments may be implemented. <figref idref="DRAWINGS">FIGS. 1</figref> and <b>2</b> are only examples and are not intended to assert or imply any limitation with regard to the environments in which different embodiments may be implemented. A particular implementation may make many modifications to the depicted environments based on the following description.

0068<figref idref="DRAWINGS">FIG. 1</figref> depicts a block diagram of a network of data processing systems in which illustrative embodiments may be implemented. Data processing environment <b>100</b> is a network of computers in which the illustrative embodiments may be implemented. Data processing environment <b>100</b> includes network <b>102</b>. Network <b>102</b> is the medium used to provide communications links between various devices and computers connected together within data processing environment <b>100</b>. Network <b>102</b> may include connections, such as wire, wireless communication links, or fiber optic cables. Server <b>104</b> and server <b>106</b> couple to network <b>102</b> along with storage unit <b>108</b>. Software applications may execute on any computer in data processing environment <b>100</b>.

0069In addition, clients <b>110</b>, <b>112</b>, and <b>114</b> couple to network <b>102</b>. A data processing system, such as server <b>104</b> or <b>106</b>, or client <b>110</b>, <b>112</b>, or <b>114</b> may contain data and may have software applications or software tools executing thereon.

0070Only as an example, and without implying any limitation to such architecture, <figref idref="DRAWINGS">FIG. 1</figref> depicts certain components that are usable in an example implementation of an embodiment. For example, servers <b>104</b> and <b>106</b>, and clients <b>110</b>, <b>112</b>, <b>114</b>, are depicted as servers and clients only as example and not to imply a limitation to a client-server architecture. As another example, an embodiment can be distributed across several data processing systems and a data network as shown, whereas another embodiment can be implemented on a single data processing system within the scope of the illustrative embodiments.

0071Device <b>132</b> is any suitable mobile computing platform, for example, a smartphone, tablet computer, a portable data processing device, an embedded device, an appliance, a device integrated into a vehicle or a system, or a wearable computing device. Device <b>132</b> includes application <b>133</b>, which implements an embodiment for constructing one or more hierarchies of elements related to UI <b>134</b> presented using the native infrastructure of device <b>132</b> as described herein. Native widgets <b>135</b> are any number or type of components of the native infrastructure of device <b>132</b>, which are responsible for creating, enforcing, applying, or otherwise managing native elements in the native infrastructure of device <b>132</b>. Client <b>112</b> similarly includes application <b>113</b>, which implements an embodiment for constructing one or more hierarchies of elements related to UI <b>111</b> presented using the native infrastructure of client <b>112</b> as described herein. Native widgets <b>115</b> are any number or type of components of the native infrastructure of client <b>112</b>, which are responsible for creating, enforcing, applying, or otherwise managing native elements in the native infrastructure of client <b>112</b>. Server <b>104</b> includes application <b>105</b>, which includes an embodiment for performing the accessibility compliance evaluation of a UI, such as UI <b>111</b> or UI <b>134</b>, where the UI's compliance is dependent upon one or more hierarchies as described herein. In one implementation, server <b>104</b> comprises one or more physical or virtual data processing systems in a cloud computing environment, and application <b>105</b> comprises a service, accessible to application <b>113</b> or <b>133</b> over network <b>102</b>. In one embodiment, application <b>105</b> can execute in device <b>132</b>, or client <b>112</b> locally.

0072In the depicted example, server <b>104</b> may provide data, such as boot files, operating system images, and applications to clients <b>110</b>, <b>112</b>, and <b>114</b>. Clients <b>110</b>, <b>112</b>, and <b>114</b> may be clients to server <b>104</b> in this example. Clients <b>110</b>, <b>112</b>, <b>114</b>, or some combination thereof, may include their own data, boot files, operating system images, and applications. Data processing environment <b>100</b> may include additional servers, clients, and other devices that are not shown.

0073In the depicted example, data processing environment <b>100</b> may be the Internet. Network <b>102</b> may represent a collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) and other protocols to communicate with one another. At the heart of the Internet is a backbone of data communication links between major nodes or host computers, including thousands of commercial, governmental, educational, and other computer systems that route data and messages. Of course, data processing environment <b>100</b> also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN). <figref idref="DRAWINGS">FIG. 1</figref> is intended as an example, and not as an architectural limitation for the different illustrative embodiments.

0074Among other uses, data processing environment <b>100</b> may be used for implementing a client-server environment in which the illustrative embodiments may be implemented. A client-server environment enables software applications and data to be distributed across a network such that an application functions by using the interactivity between a client data processing system and a server data processing system. Data processing environment <b>100</b> may also employ a service oriented architecture where interoperable software components distributed across a network may be packaged together as coherent business applications.

0075With reference to <figref idref="DRAWINGS">FIG. 2</figref>, this figure depicts a block diagram of a data processing system in which illustrative embodiments may be implemented. Data processing system <b>200</b> is an example of a computer, such as servers <b>104</b> and <b>106</b>, or clients <b>110</b>, <b>112</b>, and <b>114</b> in <figref idref="DRAWINGS">FIG. 1</figref>, or another type of device in which computer usable program code or instructions implementing the processes may be located for the illustrative embodiments. Data processing system <b>200</b> is also representative of other devices in which computer usable program code or instructions implementing the processes of the illustrative embodiments may be located. Data processing system <b>200</b> is described as a computer only as an example, without being limited thereto. Implementations in the form of other devices, such as device <b>132</b> in <figref idref="DRAWINGS">FIG. 1</figref>, may modify data processing system <b>200</b>, modify data processing system <b>200</b>, such as by adding a touch interface, and even eliminate certain depicted components from data processing system <b>200</b> without departing from the general description of the operations and functions of data processing system <b>200</b> described herein.

0076In the depicted example, data processing system <b>200</b> employs a hub architecture including North Bridge and memory controller hub (NB/MCH) <b>202</b> and South Bridge and input/output (I/O) controller hub (SB/ICH) <b>204</b>. Processing unit <b>206</b>, main memory <b>208</b>, and graphics processor <b>210</b> are coupled to North Bridge and memory controller hub (NB/MCH) 202. Processing unit <b>206</b> may contain one or more processors and may be implemented using one or more heterogeneous processor systems. Processing unit <b>206</b> may be a multi-core processor. Graphics processor <b>210</b> may be coupled to NB/MCH <b>202</b> through an accelerated graphics port (AGP) in certain implementations.

0077In the depicted example, local area network (LAN) adapter <b>212</b> is coupled to South Bridge and I/O controller hub (SB/ICH) <b>204</b>. Audio adapter <b>216</b>, keyboard and mouse adapter <b>220</b>, modem <b>222</b>, read only memory (ROM) <b>224</b>, universal serial bus (USB) and other ports <b>232</b>, and PCI/PCIe devices <b>234</b> are coupled to South Bridge and I/O controller hub <b>204</b> through bus <b>238</b>. Hard disk drive (HDD) or solid-state drive (SSD) <b>226</b> and CD-ROM <b>230</b> are coupled to South Bridge and I/O controller hub <b>204</b> through bus <b>240</b>. PCI/PCIe devices <b>234</b> may include, for example, Ethernet adapters, add-in cards, and PC cards for notebook computers. PCI uses a card bus controller, while PCIe does not. ROM <b>224</b> may be, for example, a flash binary input/output system (BIOS). Hard disk drive <b>226</b> and CD-ROM <b>230</b> may use, for example, an integrated drive electronics (IDE), serial advanced technology attachment (SATA) interface, or variants such as external-SATA (eSATA) and micro-SATA (mSATA). A super I/O (SIO) device <b>236</b> may be coupled to South Bridge and I/O controller hub (SB/ICH) <b>204</b> through bus <b>238</b>.

0078Memories, such as main memory <b>208</b>, ROM <b>224</b>, or flash memory (not shown), are some examples of computer usable storage devices. Hard disk drive or solid state drive <b>226</b>, CD-ROM <b>230</b>, and other similarly usable devices are some examples of computer usable storage devices including a computer usable storage medium.

0079An operating system runs on processing unit <b>206</b>. The operating system coordinates and provides control of various components within data processing system <b>200</b> in <figref idref="DRAWINGS">FIG. 2</figref>. The operating system may be a commercially available operating system such as AIX® (AIX is a trademark of International Business Machines Corporation in the United States and other countries), Microsoft® Windows® (Microsoft and Windows are trademarks of Microsoft Corporation in the United States and other countries), Linux® (Linux is a trademark of Linus Torvalds in the United States and other countries), iOS™ (iOS is a trademark of Cisco Systems, Inc. licensed to Apple Inc. in the United States and in other countries), or Android™ (Android is a trademark of Google Inc., in the United States and in other countries). An object oriented programming system, such as the Java™ programming system, may run in conjunction with the operating system and provides calls to the operating system from Java™ programs or applications executing on data processing system <b>200</b> (Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle Corporation and/or its affiliates).

0080Instructions for the operating system, the object-oriented programming system, and applications or programs, such as application <b>105</b>, user interface <b>111</b>, application <b>113</b>, native widgets <b>115</b>, application <b>133</b>, user interface <b>134</b>, and native widgets <b>135</b> in <figref idref="DRAWINGS">FIG. 1</figref>, are located on storage devices, such as hard disk drive <b>226</b> or a solid-state data storage device, and may be loaded into at least one of one or more memories, such as main memory <b>208</b>, for execution by processing unit <b>206</b>. The processes of the illustrative embodiments may be performed by processing unit <b>206</b> using computer implemented instructions, which may be located in a memory, such as, for example, main memory <b>208</b>, read only memory <b>224</b>, or in one or more peripheral devices.

0081The hardware in <figref idref="DRAWINGS">FIGS. 1-2</figref> may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in <figref idref="DRAWINGS">FIGS. 1-2</figref>. In addition, the processes of the illustrative embodiments may be applied to a multiprocessor data processing system.

0082In some illustrative examples, data processing system <b>200</b> may be a mobile device, which is generally configured with flash memory to provide non-volatile memory for storing operating system files and/or user-generated data. A bus system may comprise one or more buses, such as a system bus, an I/O bus, and a PCI bus. Of course, the bus system may be implemented using any type of communications fabric or architecture that provides for a transfer of data between different components or devices attached to the fabric or architecture.

0083A communications unit may include one or more devices used to transmit and receive data, such as a modem or a network adapter. A memory may be, for example, main memory <b>208</b> or a cache, such as the cache found in North Bridge and memory controller hub <b>202</b>. A processing unit may include one or more processors or CPUs.

0084The depicted examples in <figref idref="DRAWINGS">FIGS. 1-2</figref> and above-described examples are not meant to imply architectural limitations. For example, data processing system <b>200</b> also may be a tablet computer, laptop computer, or telephone device in addition to taking the form of a PDA.

0085With reference to <figref idref="DRAWINGS">FIG. 3</figref>, this figure depicts an example configuration for evaluating accessibility compliance of a hybrid user interface design in accordance with an illustrative embodiment. Application <b>302</b> is an example of application <b>113</b> or <b>133</b> in <figref idref="DRAWINGS">FIG. 1</figref>.

0086UI <b>304</b> is an example of UI <b>111</b> or <b>134</b> in <figref idref="DRAWINGS">FIG. 1</figref>. UI <b>304</b> when presented on a native infrastructure, such as that of device <b>132</b> or client <b>112</b> in <figref idref="DRAWINGS">FIG. 1</figref>, uses some combination of one or more web elements <b>306</b>, and one or more native elements <b>308</b>.

0087The accessibility of a web element, e.g., web element <b>310</b>, can be affected by a native element. Consider, as an example of web element <b>310</b>, a text field web element in an html page of UI <b>304</b>. A color contrast attribute, a font attribute, a font size attribute, or some combination of one or more of these or other attributes may be set by the UI designer to specific values. Assume for example that the font size is set to 14 by the designer, and that font size meets a given accessibility specification. When UI <b>304</b> is presented on device <b>132</b>, a native element in native elements <b>308</b> overrides the font size attribute and sets the font size of the text field to 6, which causes a compliance violation with the given accessibility specification.

0088The example scenario of a web element being affected by a native element is presented only to clarify the description of <figref idref="DRAWINGS">FIG. 3</figref>, and is not intended to imply a limitation on the illustrative embodiments. From this disclosure, those of ordinary skill in the art will be able to conceive many other scenarios in which a native element's influence over a non-native element can be found, and the same are contemplated within the scope of the illustrative embodiments.

0089Likewise, the accessibility of a native element, e.g., native element <b>312</b>, can be affected by a native element. Consider, as an example of native element <b>312</b>, a button native element in a native infrastructure, such as a graphical “Home” button on some iOS and Android devices. A size attribute, a color attribute, a spacing attribute, or some combination of one or more of these or other attributes may be set by the native infrastructure developer of device <b>132</b> to specific values. Assume for example that the spacing between the Home button and any other adjacent graphical artifact on device <b>132</b>'s screen is set to 10 pixels by the developer, and that spacing meets a given accessibility specification. When UI <b>304</b> is presented on device <b>132</b>, a web element in web elements <b>306</b> is so presented that the separation between that web element and the Home button is reduced to 6 pixels, which causes a compliance violation with the given accessibility specification.

0090The example scenario of a native element being affected by a web element is presented only to clarify the description of <figref idref="DRAWINGS">FIG. 3</figref>, and is not intended to imply a limitation on the illustrative embodiments. From this disclosure, those of ordinary skill in the art will be able to conceive many other scenarios in which a web element's influence over a native element can be found, and the same are contemplated within the scope of the illustrative embodiments.

0091Application <b>302</b> constructs web hierarchy <b>314</b> for accessibility analysis, native hierarchy <b>316</b> for accessibility analysis, and establishes the relationships between one or more elements of web hierarchy <b>314</b> and one or more elements of native hierarchy <b>316</b>. Application <b>302</b> sends web hierarchy <b>314</b> and native hierarchy <b>316</b> for web accessibility compliance checking <b>318</b>, such as to application <b>105</b> in server <b>104</b> in <figref idref="DRAWINGS">FIG. 1</figref>. Application <b>302</b> sends web hierarchy <b>314</b> and native hierarchy <b>316</b> native accessibility compliance checking <b>320</b> to application <b>105</b> or a different instance of application <b>105</b>.

0092The compliance checking at one or more instances of application <b>105</b> produces report <b>322</b>. According to one embodiment, report <b>322</b> is a unified report, which informs about any web elements as well as any native elements that are the reason for an accessibility violation.

0093With reference to <figref idref="DRAWINGS">FIG. 4</figref>, this figure depicts a block diagram of a configuration for evaluating accessibility compliance of a hybrid user interface design in accordance with an illustrative embodiment. Client data processing system <b>402</b> (client) is an example of client <b>112</b> or device <b>132</b> in <figref idref="DRAWINGS">FIG. 1</figref>. Network <b>404</b> is an example of network <b>102</b> in <figref idref="DRAWINGS">FIG. 1</figref>. Data processing system <b>406</b> (server) can be a server data processing system, such as server <b>104</b> in <figref idref="DRAWINGS">FIG. 1</figref>, or a combination of one or more physical and virtual data processing systems in a cloud computing environment. Repository <b>408</b> can be implemented using storage <b>108</b> in <figref idref="DRAWINGS">FIG. 1</figref>.

0094In operation, client <b>402</b> presents a UI including one or more accessibility features. Non-native interface description <b>410</b> contains a description of the web elements of the UI, including one or more web elements implementing the one or more accessibility features. Native interface description <b>411</b> contains a description of the native elements used in the native infrastructure of client <b>402</b>, including one or more native elements implementing the one or more accessibility features.

0095Hierarchy construction application <b>412</b> (client application) uses a model or document <b>410</b>, for example, DOM or a web page, in the manner described elsewhere in this disclosure, to construct web hierarchy <b>414</b>A. Hereinafter, such model, document, page, or other manifestation thereof is collectively referred to as non-native interface description. Client application <b>412</b> uses description <b>411</b>, e.g., a suitable description of the native infrastructure in XML or other suitable form, in the manner described elsewhere in this disclosure, to construct native hierarchy <b>414</b>B. Hereinafter, such description or any suitable manifestation thereof is collectively referred to as native infrastructure description.

0096Web hierarchy <b>414</b>A organizes certain web elements used in or reachable from the UI, such that the organization can be evaluated for accessibility compliance in the manner of an embodiment. Native hierarchy <b>414</b>B organizes certain native elements used in or influencing the presentation of the UI on client <b>402</b>, such that the organization can be evaluated for accessibility compliance in the manner of an embodiment.

0097Client application <b>412</b> sends accessibility hierarchies <b>414</b>A and <b>414</b>B over network <b>404</b> to one or more data processing systems executing one or more instances of evaluation application <b>105</b> of <figref idref="DRAWINGS">FIG. 1</figref>. Only as an example, and without implying any limitation thereto, assume that different instances of the evaluation application are used in a given configuration to evaluate the accessibility compliance of different hierarchies.

0098For example, server <b>406</b> executes evaluation application <b>416</b>. Evaluation application <b>416</b> receives web hierarchy <b>414</b>A. Component <b>418</b> selects one or more rules from web accessibility compliance rules <b>420</b> in repository <b>408</b>. Component <b>418</b> evaluates the accessibility attributes of the web elements in web hierarchy <b>414</b>A for compliance with the accessibility parameters defined in a selected web accessibility compliance rule.

0099Component <b>422</b> produces accessibility compliance report <b>424</b>. Depending on the particular implementation, report <b>424</b> may include compliance failure description of certain web elements of the UI, failure and compliance descriptions of certain web elements, a degree of severity of a compliance failure, a recommendation to remedy a compliance failure, or a combination thereof.

0100In one embodiment (not shown), evaluation application <b>416</b> in server <b>406</b> can also perform accessibility compliance checking of native hierarchy <b>414</b>B using native accessibility compliance rules <b>470</b> in repository <b>458</b>. Furthermore repository <b>458</b> and repository <b>408</b> may wholly or partially overlap (not shown).

0101In an embodiment, as shown, server <b>456</b> executes evaluation application <b>466</b>. Evaluation application <b>466</b> receives web hierarchy <b>414</b>B. Component <b>468</b> selects one or more rules from native accessibility compliance rules <b>470</b> in repository <b>458</b>. Component <b>468</b> evaluates the accessibility attributes of the native elements in native hierarchy <b>414</b>B for compliance with the accessibility parameters defined in a selected native accessibility compliance rule.

0102Component <b>472</b> contributes information about the accessibility compliance issues related to native elements to accessibility compliance report <b>424</b>. Depending on the particular implementation, report <b>424</b> may include compliance failure description of certain native elements of the UI, failure and compliance descriptions of certain web elements, failure and compliance descriptions of certain native elements, failure and compliance descriptions of a web element because of a native element, failure and compliance descriptions of a native element because of a web element, a degree of severity of a compliance failure, or a combination thereof. Report <b>424</b> may also include a recommendation to remedy a compliance failure in a web element by manipulating the web element, a recommendation to remedy a compliance failure in a web element by manipulating the native element, a recommendation to remedy a compliance failure in a native element by manipulating the web element, a recommendation to remedy a compliance failure in a native element by manipulating the native element, or a combination thereof.

0103In one embodiment, client <b>402</b> receives report <b>424</b>. Report <b>424</b> may be useful to, for example, a user who may be interacting with the UI or an application that may be presenting the UI. As another example, report <b>424</b> may be useful to an entity other than the user or the application, such as to a standards body, a manufacturer of the application, a developer of the native infrastructure of client <b>402</b>, a public interest group, or a regulating entity.

0104With reference to <figref idref="DRAWINGS">FIG. 5</figref>, this figure depicts a block diagram of an example hybrid UI whose accessibility can be evaluated in accordance with an illustrative embodiment. Device <b>502</b> is an example of device <b>132</b> or client <b>112</b> in <figref idref="DRAWINGS">FIG. 1</figref>. The relationships between a device, the device's components in the device's native infrastructure, non-native elements of a UI, and native elements of the device's native infrastructure are explained in this figure by way of non-limiting examples of such artifacts.

0105The native infrastructure of device <b>502</b> includes any number or types of device components (native components), such as native components <b>504</b>, <b>506</b>, and <b>508</b>. For example, native component <b>404</b> may be a camera, native component <b>506</b> may be an accelerometer, and native component <b>508</b> may be a Global Positioning System (GPS) module.

0106Native element <b>510</b> is an example webView container native element, which implements the browser used for presenting UI <b>514</b>. Certain attributes of webView container <b>510</b> govern how UI <b>514</b> is presented in webView <b>510</b> in device <b>502</b>.

0107Only as an example, assume that UI <b>514</b> is a web interface implemented in html and includes any number or type of web elements, such as button <b>516</b>, text field <b>518</b>, and other web elements <b>520</b>.

0108In many cases, a native component of a device is accessible to a UI via a native element. For example, if a web element of a UI needed to access the camera on a device, the web element has to refer to or use a native component in the device's native infrastructure to use such a native component. Access to GPS components, accelerometer of the device, audio/video controls, plug-in peripherals, kernel services, log data, and many other native components is controlled or marshaled through native elements in this manner.

0109For example, web element ‘button’ <b>516</b> may have to grayed out when the device is moving, but data of accelerometer <b>506</b> to determine whether the device is moving is available through example native element ‘button’ <b>522</b>. Many native elements may be available in the native infrastructure of device <b>502</b> for a similar purpose or other reasons. ‘Label’ <b>524</b> is another example native element, as is text field <b>526</b>.

0110Any number or type of native elements may be similarly available in the native infrastructure of device <b>502</b>. For example, web element ‘text field’ <b>518</b> may use the GPS information of native component <b>508</b> by looking-up or otherwise using native element ‘text field’ <b>526</b>. A web element in web elements <b>520</b> may access camera component <b>504</b> by calling, referring to, or otherwise using a native component in native elements <b>528</b>. Such use by or reliance upon a native element by a web element affects the accessibility compliance of the web element, the native element, or both.

0111With reference to <figref idref="DRAWINGS">FIG. 6</figref>, this figure depicts a process of generating a hierarchy of elements for evaluating accessibility compliance of a UI design in accordance with an illustrative embodiment. Hierarchy <b>602</b> is an example organization of example UI elements, such as interface description <b>410</b> or native infrastructure description <b>411</b> in <figref idref="DRAWINGS">FIG. 4</figref>. Hierarchy <b>652</b> is an example of web hierarchy <b>414</b>A or native hierarchy <b>414</b>B (collectively, “accessibility hierarchy”) generated by hierarchy construction application <b>412</b> in <figref idref="DRAWINGS">FIG. 4</figref>, corresponding to interface description <b>410</b> or native infrastructure description <b>411</b>, respectively. The description of this figure describes the operations of an embodiment with respect to web elements in a web hierarchy of a UI only as examples and not to imply any limitations. The embodiment is adaptable to produce a native hierarchy by operating the embodiment by using native elements from a corresponding native infrastructure definition in a similar manner.

0112Only as an example, and without implying any limitation thereto, assume that the UI is an interface from an iOS application using iOS platform. Interface hierarchy <b>602</b> begins at node “view” <b>604</b>. Node <b>604</b> is a container element node because node <b>604</b> is a parent node to one or more other nodes, such as example nodes <b>606</b>, <b>608</b>, and <b>610</b>. Assume that node <b>606</b> is a view type container element, and includes leaf node <b>612</b>, which is some textual visual content. Leaf node <b>612</b> is an individual element because leaf node <b>612</b> is not a parent to any other node in interface hierarchy <b>602</b>. Only as an example to illustrate the operation of an embodiment, assume that individual element <b>612</b> comprises static textual content.

0113Similarly, node <b>608</b> is a container node of type “view group” and includes another “view group” type container element <b>614</b>. Node <b>610</b> is a layout type container element, and among other things, includes text-field type individual element <b>616</b> for content. Again, only as an example to illustrate the operation of an embodiment, assume that individual element <b>612</b> comprises audio or video content.

0114Container element <b>614</b> includes another container element <b>618</b>, which is a table type container element. Table <b>618</b> includes, among other things, individual nodes <b>620</b> and <b>622</b>. Only as an example to illustrate the operation of an embodiment, assume that individual element <b>620</b> is a text-field type element and comprises active or dynamically-generated content. Individual element <b>622</b> is a button type control element on the UI, which allows some action to be performed on the active content of individual element <b>620</b>. Active or dynamically generated content, as in individual node <b>620</b>, is an element of a UI whose exact nature or type is not specified or described in the interface description or interface hierarchy <b>602</b>, but it resolved or populated on the UI at run-time. As an example, assume that dynamically generated content <b>620</b> under certain circumstances would result in a uniform resource locator (URL), a link, to some content that calls, launches, or presents additional controls. Some examples of such content are audio or video data, reference to launch another application (which may present another UI), and data to transition to another UI within the application.

0115An application implementing an embodiment, such as hierarchy construction application <b>412</b> in <figref idref="DRAWINGS">FIG. 4</figref>, roots accessibility hierarchy <b>652</b> at container element <b>604</b>A, which corresponds to node <b>604</b> in interface hierarchy <b>602</b>. If any view-level accessibility attributes are defined or available for node <b>604</b>, the application selects and adds those attributes to node <b>604</b>A.

0116Given the example static content of node <b>612</b> as described above, in an example operation, the application determines that nodes <b>606</b> and <b>612</b> are not candidates for accessibility features. Accordingly, the application omits including nodes corresponding to nodes <b>606</b> and <b>612</b> in accessibility hierarchy <b>652</b>.

0117The application similarly adds nodes <b>608</b>A, <b>612</b>A, <b>614</b>A, <b>616</b>A, <b>618</b>A, <b>620</b>A, and <b>622</b>A to accessibility hierarchy <b>652</b>. Nodes <b>608</b>A, <b>614</b>A, <b>616</b>A, <b>618</b>A, <b>620</b>A, and <b>622</b>A correspond to nodes <b>608</b>, <b>614</b>, <b>616</b>, <b>618</b>, <b>620</b>, and <b>622</b>, respectively, in interface hierarchy <b>602</b>. Where available or determinable, the application adds the accessibility attributes to a node in accessibility hierarchy <b>652</b>. For example, node <b>622</b> may not include any accessibility attributes in interface hierarchy <b>602</b>; however, nodes <b>614</b> and <b>618</b>—both of which are parent nodes to node <b>622</b>, may define same or distinct accessibility attributes. Accordingly, the application determines that node <b>622</b> inherits at least a subset of the accessibility attributes from one or both parent nodes. The application therefore adds such a subset of accessibility attributes to node <b>622</b>A in accessibility hierarchy <b>652</b>.

0118Note that in one embodiment, adding the subset of accessibility attributes to node <b>622</b>A can be avoided if the parent-child relationship of node <b>622</b>A with other nodes in accessibility hierarchy <b>652</b> remains the same as the parent-child relationships of corresponding node <b>622</b> in interface hierarchy <b>602</b>, and that subset of accessibility attributes remains available at node <b>622</b>A through such relationships in accessibility hierarchy <b>652</b>. In another embodiment, adding the subset of accessibility attributes to node <b>622</b>A is needed if the parent-child relationship of node <b>622</b>A with other nodes in accessibility hierarchy <b>652</b> is different from the parent-child relationships of corresponding node <b>622</b> in interface hierarchy <b>602</b>, owing to any reorganization, omission, addition, or replication operations performed by the application in accessibility hierarchy <b>652</b>. Due to such operations, the subset of accessibility attributes available at node <b>622</b> would not available through the relationships of node <b>622</b>A in accessibility hierarchy <b>652</b>, and has to be expressly added to node <b>622</b>A to correctly communicate the accessibility features of node <b>622</b> on the UI.

0119Given the example audio or video content of node <b>616</b> as described above, in an example operation, the application determines that node <b>616</b> will call or present additional controls or elements that should be evaluated for accessibility even though such controls or elements are not described in interface hierarchy <b>602</b>. Accordingly, using a suitable process, determines another UI that will be launched or presented for interacting with the audio or video content of node <b>616</b>. The application identifies the controls or elements such other UI does include or would include. The application includes nodes corresponding to such controls or elements as nodes <b>654</b> and <b>656</b> in accessibility hierarchy <b>652</b>.

0120Without implying any limitation thereto, one example process for identifying the other UI can include examining configuration information for the application that presents the UI of interface hierarchy <b>602</b>. Such examining reveals the identity, location, and configuration of the plugin that would be launched to interact with audio or video content. Any suitable method, e.g., an application program interface (API) call, can then be used to determine the UI the plugin presents, and the controls or elements situated thereon.

0121An embodiment can then operate on such other UI and the controls or elements to determine their accessibility attributes. Once determines, nodes <b>654</b> and <b>656</b> can be constructed for such controls or elements, and their accessibility attributes can be used to populate the accessibility attributes of nodes <b>654</b> and <b>656</b>.

0122Given the example active or dynamically generated content of node <b>620</b> as described above, in an example operation, the application determines that node <b>620</b> will call or present additional controls or elements that should be evaluated for accessibility even though such controls or elements are not described in interface hierarchy <b>602</b>. Accordingly, using a suitable process, additional elements that will be presented for interacting with the active content of node <b>620</b>. The application identifies the controls or elements, which may themselves be in some hierarchy. Accordingly, the application includes nodes corresponding to such organization of controls or elements as nodes <b>658</b>, <b>660</b>, and <b>662</b>, along with their determined accessibility attributes, in accessibility hierarchy <b>652</b>.

0123In some implementations, an application that presents the UI corresponding to interface hierarchy <b>602</b> may allow identifying the application exactly or by a class or category of the application. Under certain circumstances, a user of the UI may similarly allow identifying the user exactly or by a class or category of the user. Thus, an embodiment associates one or more profiles, normalized profiles, or a combination thereof, <b>664</b>, with accessibility hierarchy <b>652</b>. A normalized profile can describe a class of applications that present similar UIs or accessibility features. A normalized profile can also describe a persona, e.g., a characteristic or feature common to a class of users.

0124The example process of defining nodes <b>654</b>-<b>662</b> is not intended to be limiting on the illustrative embodiments. From this disclosure, those of ordinary skill in the art will be able to conceive other ways of identifying UI elements not specified in interface hierarchy <b>602</b>, identifying their accessibility attributes, and including them in accessibility hierarchy <b>652</b>. Such other ways are implementation dependent and therefore not conducive to exhaustive listing or description herein, but are contemplated within the scope of the illustrative embodiments.

0125As stated earlier, the embodiment is adaptable to produce a native hierarchy by operating the embodiment by using native elements from a corresponding native infrastructure definition in a similar manner. Furthermore, when a web element in hierarchy <b>652</b> is influenced or affected by a native element, such relationship is also notated in the corresponding web element in hierarchy <b>652</b>. The influencing or affecting native element of a native hierarchy similar to hierarchy <b>652</b> is reachable from such a notated web element in hierarchy <b>652</b>.

0126Conversely, when hierarchy <b>652</b> is a native hierarchy, and a native element in hierarchy <b>652</b> is influenced or affected by a web element, such relationship is similarly notated in the corresponding native element in hierarchy <b>652</b>. The influencing or affecting web element of a web hierarchy is reachable from such a notated native element in hierarchy <b>652</b>.

0127In one embodiment, the notation includes a copy of the influencing or affecting element within the influenced or affected element. In another embodiment, the notation comprises a reference within the influenced or affected element to the influencing or affecting element. In another embodiment, the notation comprises an attribute of the influencing or affecting element within the influenced or affected element. In another embodiment, the notation comprises a reference within the influenced or affected element to an attribute of the influencing or affecting element.

0128More than one influencer elements in one hierarchy <b>652</b> may influence an element in another hierarchy <b>652</b>. Accordingly, more than one inclusions, references, or a combination thereof, are possible in an element of hierarchy <b>652</b> within the scope of the illustrative embodiments. <figref idref="DRAWINGS">FIGS. 7A and 7B</figref> depict some examples of such inclusions and references.

0129With reference to <figref idref="DRAWINGS">FIG. 7A</figref>, this figure depicts a block diagram of an example way of representing elements of a hybrid UI in accordance with an illustrative embodiment. Native hierarchy <b>702</b> is an example of hierarchy <b>652</b> of <figref idref="DRAWINGS">FIG. 6</figref>, when hierarchy <b>652</b> represents an organization of native elements used in presenting a UI. Elements <b>704</b> and <b>706</b> are example elements in hierarchy <b>702</b>.

0130As an example, element <b>704</b> is a container element node and element <b>706</b> is a leaf node in hierarchy <b>702</b>. Furthermore, container element <b>704</b> is an example webView container as described earlier, such as webView container <b>510</b> in <figref idref="DRAWINGS">FIG. 5</figref>.

0131Web hierarchy <b>708</b> is another instance of hierarchy <b>652</b> in <figref idref="DRAWINGS">FIG. 6</figref>, and represents the web elements of the UI presented in webView container. Assume that in this non-limiting example depiction, the entirety of web hierarchy <b>708</b> is dependent upon webView container <b>704</b>. Accordingly, web hierarchy <b>708</b> is represented in this figure as being referenceable or reachable from webView container element <b>704</b>.

0132With reference to <figref idref="DRAWINGS">FIG. 7B</figref>, this figure depicts a block diagram of another example way of representing elements of a hybrid UI in accordance with an illustrative embodiment. Native hierarchy <b>702</b> is an example of hierarchy <b>652</b> of <figref idref="DRAWINGS">FIG. 6</figref>, when hierarchy <b>652</b> represents an organization of native elements used in presenting a UI. Elements <b>754</b> and <b>756</b> are example elements in hierarchy <b>752</b>.

0133Web hierarchy <b>758</b> is another instance of hierarchy <b>652</b> in <figref idref="DRAWINGS">FIG. 6</figref>, and represents the web elements of a UI presented using the native elements of native hierarchy <b>752</b>. Assume that in this non-limiting example depiction, accessibility attributes of web element <b>760</b> can be modified by native element <b>756</b>. Accordingly, native element <b>756</b> is referenced and reachable from web element <b>760</b> during accessibility compliance analysis. Assume as another example, that native element <b>754</b> is influenced by web element <b>764</b>, which is a part of web container element <b>762</b>. Accordingly, native element <b>754</b> references web element <b>764</b>, and web element <b>764</b> is reachable from native element <b>754</b> during accessibility compliance analysis.

0134With reference to <figref idref="DRAWINGS">FIG. 8</figref>, this figure depicts a flowchart of an example process for constructing an accessibility hierarchy in accordance with an illustrative embodiment. Process <b>800</b> can be implemented in hierarchy construction application <b>412</b> in <figref idref="DRAWINGS">FIG. 4</figref>. Process <b>800</b> produces an accessibility hierarchy, such as example accessibility hierarchy <b>652</b> in <figref idref="DRAWINGS">FIG. 6</figref>, for accessibility compliance evaluation. As with several other embodiments described herein, process <b>800</b> is described using web elements and a web hierarchy only as an example and not as a limitation. Process <b>800</b> can similarly be adapted based on this disclosure to produce native hierarchies of native elements within the scope of the illustrative embodiments.

0135The application detects an event or a change at a client data processing system (block <b>802</b>). The application determines whether a new or updated accessibility hierarchy is needed responsive to the event (block <b>804</b>). For example, the application determines whether the UI that is presented in response to the event has been changed, and the change has not yet been mapped to an accessibility hierarchy, or has changed since it was last mapped an accessibility hierarchy. If a new or updated accessibility hierarchy is not needed (“No” path of block <b>804</b>), the application ends process <b>800</b> thereafter, or returns to block <b>802</b> (not shown) and awaits detecting another event.

0136If a new or updated accessibility hierarchy is needed (“Yes” path of block <b>804</b>), the application retrieves, detects, or otherwise selects an interface description for the UI that is responsive to the event (block <b>806</b>). The application selects an element in the interface description (block <b>808</b>). Optionally, depending on the nature of the selected element, the application may omit including the element into the accessibility hierarchy being constructed (block <b>810</b>). Omitting element <b>612</b> of <figref idref="DRAWINGS">FIG. 6</figref> is an example omission according to block <b>810</b>. Upon omitting an element, the application returns process <b>800</b> to select another element at block <b>808</b>.

0137When not omitted, the application determines a type of the selected element (block <b>812</b>). If the element is an individual element (“Individual” path of block <b>812</b>), for example, element <b>622</b> of <figref idref="DRAWINGS">FIG. 6</figref>, the application proceeds to block <b>818</b>. If the element is a container element (“Container” path of block <b>812</b>), for example, element <b>618</b> of <figref idref="DRAWINGS">FIG. 6</figref>, the application selects a contained element, to wit, a leaf node or an individual element, or another container element in the selected element (block <b>814</b>). The application proceeds to block <b>818</b> thereafter. If the element indicates further unspecified elements, or an element that is resolved at run-time (“Unspecified/run-time” path of block <b>812</b>), for example, element <b>616</b> of <figref idref="DRAWINGS">FIG. 6</figref>, the application identifies an element of the interface presented at run-time (block <b>816</b>). The application proceeds to block <b>818</b> thereafter.

0138The application adds the individual element, the container and contained elements, or the element from the run-time interface, as the case may be, along with the corresponding set of stated, derived, or computed accessibility attributes, to the accessibility hierarchy (block <b>818</b>). Depending on the nature of the container element or the run-time interface, the application may return to blocks <b>814</b> or <b>816</b>, respectively, until all elements in the container or the run-time interface have been added (or omitted) at block <b>818</b>. The application may also resolve and calculate new values for the affected attribute.

0139The application determines whether the element of block <b>818</b> has a relationship with or dependency on an element in another hierarchy (block <b>820</b>). If no such relationship or dependency exists (“No” path of block <b>820</b>), the application proceeds to block <b>826</b>. If a relationship or dependency exists (“Yes” path of block <b>820</b>), the application identifies an element in the other hierarchy with which the relationship or dependency exists (block <b>822</b>). The application notates the dependency or relationship in or relative to the element of block <b>818</b>.

0140The application determines whether more elements remain in the interface description (block <b>826</b>). If more elements remain in the interface description (“Yes” path of block <b>826</b>), the application returns to block <b>808</b> and selects another element. If no more elements remain in the interface description (“No” path of block <b>826</b>), the application sends the accessibility hierarchy thus constructed, and all or part of one or more other related hierarchies according to the operations of blocks <b>820</b>, <b>822</b>, and <b>824</b>, for accessibility evaluation, such as to process <b>900</b> of <figref idref="DRAWINGS">FIG. 9</figref>, (block <b>828</b>). The application ends process <b>800</b> thereafter.

0141In one embodiment, the application associates (not shown) one or more profiles or normalized profiles with the accessibility hierarchy before sending in block <b>828</b>. The selection and association of profiles or normalized profiles can be performed in any suitable manner within the scope of the illustrative embodiments.

0142With reference to <figref idref="DRAWINGS">FIG. 9</figref>, this figure depicts a flowchart of an example process for evaluating accessibility compliance of a hybrid UI design in accordance with an illustrative embodiment. Process <b>900</b> can be implemented in evaluation application <b>416</b> and/or <b>456</b> of <figref idref="DRAWINGS">FIG. 4</figref>, to generate report <b>424</b> of <figref idref="DRAWINGS">FIG. 4</figref>.

0143The application, such as evaluation application <b>416</b> of <figref idref="DRAWINGS">FIG. 4</figref>, receives an accessibility hierarchy (block <b>602</b>). For example, the accessibility hierarchy received in block <b>602</b> can be the accessibility hierarchy sent at block <b>522</b> in process <b>500</b> of <figref idref="DRAWINGS">FIG. 5</figref>. As with several other embodiments described herein, process <b>900</b> is described using web elements and a web hierarchy only as an example and not as a limitation. Process <b>900</b> can similarly be adapted based on this disclosure to produce native hierarchies of native elements within the scope of the illustrative embodiments.

0144The application determines a manner of selecting an accessibility compliance rule, such as from rules <b>420</b> in repository <b>408</b> of <figref idref="DRAWINGS">FIG. 4</figref> (block <b>904</b>). The selected rule can be any number and type of rules, e.g., a rule specific to a device, an application, an enterprise, a geography, a special case, a time, a purpose, an entity, a requirement, a usability, or a condition. When a standards-based rule or a default rule is to be selected (“standard/default” path of block <b>904</b>), the application selects a rule according to the pertinent standard or default setting (block <b>906</b>).

0145The application may determine to select one rule for the entire hierarchy, or apply multiple rules to the same hierarchy either one by one, or different rules for different nodes in the same hierarchy, depending on the particular needs of a given implementation.

0146When a user-specific rule is to be selected (“profile-specific” path of block <b>904</b>), the application identifies the user or a category of the user according to a profile or a normalized profile of the user or user's category, respectively, associated with the hierarchy received in block <b>902</b> (block <b>908</b>). The application selects a rule according to the identified user or user category (block <b>910</b>).

0147When an application-specific rule is to be selected (“application-specific” path of block <b>904</b>), the application identifies the application or a category of the application according to an application profile or a normalized profile of an application category, respectively, associated with the hierarchy received in block <b>902</b> (block <b>912</b>). The application selects a rule according to the identified application or application category (block <b>914</b>).

0148The application selects an element from the hierarchy (block <b>916</b>). In one embodiment, additional or different rules may be applicable to the element selected in block <b>916</b>. Accordingly, the embodiment selects such additional or different rules (not shown) as a part of block <b>916</b>.

0149The application determines whether, according to the selected rule, including any additional or different element-specific rules, the selected element should be evaluated for accessibility (block <b>918</b>). For example, even though an element of a UI may include an accessibility attribute, a selected rule may not require accessibility for that type of elements, or may not require compliance evaluation for such offered accessibility.

0150If the selected element should not be evaluated for accessibility (“No” path of block <b>918</b>), the application returns to block <b>916</b> and selects another element. If the selected element should be evaluated for accessibility (“Yes” path of block <b>918</b>), the application determines whether one or more accessibility attributes have been enabled for the element, associated with the element, or derivable for the element from a parent of the element (block <b>920</b>). If so (“Yes” path of block <b>920</b>), the application analyzes the suitability of such accessibility attribute according to the selected rule (block <b>922</b>).

0151If not (“No” path of block <b>920</b>), the application optionally determines a degree of severity of the compliance failure for not associating an accessibility attribute with the element (block <b>924</b>). The application further, optionally, determines a remedial action to correct the compliance failure (block <b>926</b>). The remedial action may be specified in the rule, may be determinable from the rule, may be specified for use in conjunction with the rule, or otherwise identifiable based on the rule. The application reports the non-compliance of the element, with optional degree of severity and/or remedial actions (block <b>928</b>).

0152From block <b>922</b>, the application determines whether the analysis of block <b>922</b> indicates that the element has met the accessibility requirements of the selected rule (block <b>930</b>). The rule requirement check of block <b>930</b> incorporates any element-specific additional or different rules when such additional or different rules are selected in block <b>916</b> (not shown). If not (“No” path of block <b>930</b>), the application performs the operation of block <b>928</b>. If the accessibility of the selected element meets the accessibility requirement of the rule (“Yes” path of block <b>930</b>), the application optionally reports the in-compliance status of the element (block <b>932</b>).

0153The application determines whether more elements are to be similarly analyzed from the accessibility hierarchy of block <b>902</b> (block <b>934</b>). If so (“Yes” path of block <b>934</b>), the application returns process <b>900</b> to block <b>916</b> to select another element. In one embodiment, additional or different rules may be applicable to the element selected in block <b>916</b>. Accordingly, the embodiment selects such additional or different rules (not shown) as a part of block <b>916</b>. The rule requirement check of block <b>930</b> incorporates such additional or different rules in such an embodiment. Note that there can be rules that are applicable to both types of elements—the non-native elements as well as the native elements. The application may select the same rule for different elements, including different types of elements, under certain circumstances within the scope of the illustrative embodiments.

0154If not (“No” path of block <b>934</b>), the application outputs the accessibility compliance report, e.g., report <b>424</b> in <figref idref="DRAWINGS">FIG. 4</figref> (block <b>936</b>). The application ends process <b>900</b> thereafter.

0155With reference to <figref idref="DRAWINGS">FIG. 10</figref>, this figure depicts an example process for unifying or creating a unified accessibility compliance report in accordance with an illustrative embodiment. Process <b>1000</b> can be implemented in evaluation application <b>416</b> and/or <b>456</b> of <figref idref="DRAWINGS">FIG. 4</figref>, to generate report <b>424</b> of <figref idref="DRAWINGS">FIG. 4</figref>.

0156The application determines if a selected element is related to an element of another hierarchy (block <b>1002</b>). Such a determination can be made, for example, using the notations made in the selected element by process <b>800</b> of <figref idref="DRAWINGS">FIG. 8</figref>. If no relationship exists (“No” path of block <b>1002</b>), the application ends process <b>1000</b> for that selected element thereafter. If a relationship exists (“Yes” path of block <b>1002</b>), the application performs process <b>900</b> or a part thereof as depicted in <figref idref="DRAWINGS">FIG. 9</figref>, on the related element of the other hierarchy (block <b>1004</b>).

0157The application combines the accessibility analysis findings of that related element in the report being prepared in block <b>928</b> of process <b>900</b> for the selected element (block <b>1006</b>). The application ends process <b>1000</b> thereafter.

0158With reference to <figref idref="DRAWINGS">FIG. 11</figref>, this figure depicts another example process for unifying or creating a unified accessibility compliance report in accordance with an illustrative embodiment. Process <b>1100</b> can be implemented in evaluation application <b>416</b> and/or <b>456</b> of <figref idref="DRAWINGS">FIG. 4</figref>, to generate report <b>424</b> of <figref idref="DRAWINGS">FIG. 4</figref>.

0159The application receives or accesses the accessibility analysis reports of all related hierarchies for a given UI (block <b>1102</b>). The application combines or unifies the reports, such as by arranging related elements from different hierarchies together relative to an identified accessibility compliance failure in the report (block <b>1104</b>). Optionally, the application recommends resolving a violation by referencing the specific elements in one or more related hierarchies (block <b>1106</b>). The application ends process <b>1100</b> thereafter.

0160Thus, a computer implemented method, system or apparatus, and computer program product are provided in the illustrative embodiments for evaluating accessibility compliance of a hybrid user interface design. While the embodiments and examples are described with respect to checking accessibility compliance of a UI, the illustrative embodiments are similarly usable for other use-cases as well, and the same are contemplated within the scope of the illustrative embodiments. For example, using this disclosure, an embodiment can be configured to check compliance of a hybrid UI with usability rules, user-friendliness specifications, security rules, regulatory compliance rules, and other types of rules within the scope of the illustrative embodiments.

0161Furthermore, the embodiments are described with respect to iOS, iOS elements, browsers, html, and web elements only as examples. Other environments can also act as, or participate in, a native infrastructure. For example, the UI may include Adobe Flash content presented within Adobe Flash player, where the native elements may be a part of the player, and non-native elements may be contributed by the Flash content. (Adobe and all Adobe related marks are trademarks of Adobe Systems Incorporated, in the United States and in other countries.)

0162The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

0163The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

0164Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

0165Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

0166Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

0167These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

0168The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

0169The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.