# Exploring Variability of Visual Accessibility Options in Operating Systems
## 3 Data Preparation
### Modeling Accessibility Mechanisms through Features Models  
The formalism for modeling options in a single operating system is borrowed from the product line engineering paradigm [25]. In this paradigm, the high-level features are gathered in feature sets and then organized into Feature Models (FMs). FMs are kinds of logical trees [23; 24]. The nodes represent the features and the child-parent edges represent various types of refinement. Decorations on edges give information about optionality versus obligation, and about feature groups (Or, Xor). The FMs also include textual logical constraints. At the data-mining step, we will consider only the features and child-parent relationships. Textual constraints will not be considered in this paper. Nevertheless, we thought useful to formalize them for exhaustive description and further research. Figure 2 (left-hand side) shows the FM for brightness in operating system _iOS5_. In this system, an end user configuration contains or may contain:  
* the root feature _iOS5_Brightness_ (mandatorily);
* feature _DisplayAndBrightness_ (mandatorily);
* feature _AutoBrightness_ (optionally);
* features _Brightness_ and _Interval_From_Zero_To_OneHundredPercent_ (mandatorily). Let us note that alternative modeling could be done during this phase. For example, all possible values of brightness (if in finite number) could be shown as different features in an Xor group, rather than making explicit an interval and its bounds. FM building is summarized as follows (Box 1). **Box 1. ** Feature Model building. **FM building. ** Let us denote the set of operating systems by \(OS=\{\textit{Android5.1}\), _Android6.0_, _iOS5_, _MacOS10.10_, _Ubuntu12.04_, _Ubuntu14.10_, _Windows7.0_, _Windows8.1\(\}\) and the set of mechanisms by \(MS=\{\textit{Brightness},\textit{Contrast},\textit{TextStyle},\textit{Zoom}\}\). At FM building step, \(\forall ms\in MS,\forall os\in OS\), we build the _Feature Set_\(FS^{\textit{os}}_{ms}\) and the _Feature Model_\(FM^{\textit{os}}_{ms}\). The whole feature set is denoted by \(\mathcal{F}=\bigcup_{ms\in MS,\textit{ososososososososososososososososos  
term means \"manually set brightness\", can be considered a specialization of term \(Display\)_AndBrightness_ and \(iOS5\_Brightness\) in \(iOS5\). * Some options gathered during the manual exploration of systems do not describe brightness concepts, they correspond to paths in user interface, such as _OpenDisplayPreferences_ in \(MacOS10.10\). We consider that they are accidentally present for our analysis. To standardize these descriptions, we designed an ontology composed of 4 parts, one per mechanism (they also can be considered as 4 ontologies). The ontology plays the role of a formal and common vocabulary composed of concepts and relations. Each option of a particular system can be mapped onto one ontology concept. In practice, to build the brightness ontology, we analyzed the features in all the systems and we modeled and organized the underlying concepts. The brightness ontology is shown in Figure 3. It highlights the concept \(BrightnessMechanism\) which can be specialized into two types of setting functionalities: \(Display\)_AutoBrightness_ and \(ManualDisplay\)_BrightnessLevel_, represented by two sub-concepts. The first consists of enabling or disabling: if the user enables it, the system automatically sets the value. For the second one, the user chooses one value among a set of values. As a result, we define the concept \(IntervalValue\) as a specialization of \(ManualDisplay\)_BrightnessLevel_. Alternatively the setting consists to increase (resp. decrease) the brightness level. That is why we define the concepts \(IncreaseBrightness\) and \(DecreaseBrightness\) as specializations of \(Manual\)_DisplayBrightnessLevel_. In addition to specialization, other relations can be included in the ontology, and numerical values need to be represented. For example, in the text style ontology, we establish \(hasSize\) between concepts \(ThingsAreaTextSize\) and \(Size\) (see Figure 4).