scieee AI-readable full text Open interactive document viewer

Accessibility Variability Model: The UTPL MOOC Case Study

Rodríguez, Germania; Pérez, Jennifer; Benavides Cuevas, David Felipe

Abstract

Several approaches to define Variability Models (VM) of non-functional requirements or quality attributes have been proposed. However, these approaches have focused on specific quality attributes rather than more general non-functional aspects established by standards such as ISO/IEC 25010 for software evaluation and quality. Thus, developing specific software products by selecting features and at the same time measuring the level of compliance with a standard/ guideline is a challenge. In this work, we present the definition of an accessibility VM based on the web content accessibility guides (WCAG) 2.1 W3C recommendation, to obtain a quantitative measure to improve or construct specific SPL products that require to be accessibility-aware. This paper is specially focused on illustrating the experience of measuring the accessibility in a software product line (SPL) in order to check if it is viable measuring products and recommending improvements in terms of features before addressing the construction of accessibility-aware products. The adoption of the VM accessibility has been putted into practice through a pilot case study, the MOOC (Massive Open Online Course) initiative of the Universidad Técnica Particular de Loja. The conduction of this pilot case study has allowed us to illustrate how it is possible to model and measure the accessibility in SPL using accessibility VM, as well as to recommend accessibility configuration improvements for the construction of new or updated MOOC platforms.

Full text

Accessibility Variability Model: The UTPL MOOC Case Study Germania Rodriguez Universidad Politécnica de Madrid Universidad Técnica Particular de Loja Loja, Ecuador [email protected] Jennifer Pérez Universidad Politécnica de Madrid Madrid, Spain [email protected] David Benavides ETSI Informática Universidad de Sevilla Sevilla, Spain [email protected] ABSTRACT Several approaches to define Variability Models (VM) of non-functional requirements or quality attributes have been proposed. However, these approaches have focused on specific quality attributes rather than more general non-functional aspects established by standards such as ISO/IEC 25010 for software evaluation and quality. Thus, developing specific software products by selecting features and at the same time measuring the level of compliance with a standard/guideline is a challenge. In this work, we present the definition of an accessibility VM based on the web content accessibility guides (WCAG) 2.1 W3C recommendation, to obtain a quantitative measure to improve or construct specific SPL products that require to be accessibility-aware. This paper is specially focused on illustrating the experience of measuring the accessibility in a software product line (SPL) in order to check if it is viable measuring products and recommending improvements in terms of features before addressing the construction of accessibility-aware products. The adoption of the VM accessibility has been putted into practice through a pilot case study, the MOOC (Massive Open Online Course) initiative of the Universidad Técnica Particular de Loja. The conduction of this pilot case study has allowed us to illustrate how it is possible to model and measure the accessibility in SPL using accessibility VM, as well as to recommend accessibility configuration improvements for the construction of new or updated MOOC platforms. CCS CONCEPTS •Software and its engineering →Software product lines; KEYWORDS Software and its engineering, Software creation and management, Software development techniques, Reusability, Software product lines ACM Reference format: Germania Rodriguez, Jennifer Pérez, and David Benavides. 2019. Accessibility Variability Model: The UTPL MOOC Case Study. In Proceedings of 23rd International Systems and Software Product Line Conference - Volume B, Paris, France, September 9–13, 2019 (SPLC ’19), 8 pages. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. SPLC ’19, September 9–13, 2019, Paris, France ©2019 Association for Computing Machinery. ACM ISBN 978-1-4503-6668-7/19/09. ..$15.00 https://doi.org/10.1145/3307630.3342416 https://doi.org/10.1145/3307630.3342416 1 INTRODUCTION Software Product Lines Engineering (SPLE) takes advantage of the common features of a family of products and anticipates the expected degree of variation over the product’s lifetime [ 5 ],[ 13 ]. This means that SPLE exploits the commonality found in the products of the same family by using reusable core assets and the variability of the family by constructing variable assets (typically developed in a phase called domain engineering [ 13 ]), which are then customized and assembled into specific products (typically developed in a phase called application engineering [ 13 ]). SPLE implies a big-upfront investment in domain engineering, but it turns on a beneficious ROI (Return of Investment) during the application engineering phase. The complexity of current software systems makes non-functional requirements (NFR) at least as critical as functional ones. NFR are characteristics of the system that are provided as a whole, so they commonly crosscut the functionality of the system. NFR are classified from different points of views. Sommerville [ 17 ] classifies them as external, organizational and product requirements; whereas the standard ISO/IEC/IEEE 29148 [ 10 ] divides them into quality and stakeholder requirements. Depending on the standard, they are categorized in a different way, and those NFR that are highly related with the architecture and design are also called as quality attributes [ 17 ].There are standardized quality models to evaluate this quality attributes [ 9 ]. Standards and guidelines confirmed by standard committees can be used as a mechanism to measure in which degree a software product fulfils a NFR or quality attribute. The functional variability in SPL has been extended using specific quality or NFR information. In this paper, we focus on the NFR standards and guidelines, specifically in the Accessibility Web Content Accessibility Guidelines (WCAG) 2.1, W3C Recommendation [ 22 ]. This work presents the specification of the accessibility features and information that the WCAG pre-establishes being product and family independent. Therefore, it can be used for any SPL related to web accessibility. Since accessibility crosscut the functionality of products and their families, this work defines an Accessibility Variability Model, which is interconnected with a functional Variability Model [ 13 ]. In particular, it has been represented using Orthogonal Variability Models (OVM). In order to illustrate this contribution, it has been adopted in the domain engineering phase by constructing the SPL of OER family, and by deriving the Massive Open Course (MOOC) initiative of the Universidad Técnica Particular de Loja [19]. The rest of the paper is structured as follows: Section 2 provides the background about accessibility; Section 3 provides an overview SPLC ’19, September 9–13, 2019, Paris, France Germania Rodriguez, Jennifer Pérez, and David Benavides of related works; Section 4 shows the definition of accessibility OVM; Section 5 an experience study case in order to apply the accessibility OVM; and Section 6 presents conclusions and future work. 2 ACCESSIBILITY Accessibility is a key non-functional property in any application and even more so in the Web. Tim Berners-Lee argues that ‘The social value of the Web is that it enables human communication, commerce, and opportunities to share knowledge’. One of the World Wide Web Consortium [ 21 ] primary goals is to make these advantages available to all people. According to ISO 9241-11:1998 [ 12 ], accessibility is the use of a product, service, framework or resource in an efficient, effective, and satisfying way by people with different abilities . To obtain a quantitative assessment of web accessibility, some methods, standards and international guides are available. The Accessibility Evaluation Methods (AEM) may differ in terms of effectiveness, efficiency and utility [ 2 ]. Regarding standards and norms, the most representative and globally referenced are those presented in the W3C Web Accessibility Initiative (WAI) [ 20 ], that brings together people from industry, disability organizations, governments, and research centers of the world to develop guidelines and resources to help make the web more accessible to people with disabilities, from speech to auditory, cognitive, neurological, physical and visual disabilities. The WAI initiative comprises standards, guidelines and techniques in different versions. This work is focused on Websites and web applications - Web Content Accessibility Guidelines (WCAG 2.1) [ 22 ]. WCAG 2.1 covers a wide range of recommendations to make web content more accessible, and these recommendations also make web content more useful for common users. These guidelines establish three levels to structure and guide the accessibility evaluation of web contents as follow: • Principles: the foundations of web accessibility such as perceivable, operable, understandable and robust. • Guidelines: twelve guidelines that refine the principles. These guidelines provide the basic objectives that authors must achieve in order to create more accessible content for users with different levels of disability. • Success Criteria: for each of the twelve guidelines, the WCAG 2.1 provides verifiable compliance success criteria. These guidelines are used to evaluate requirements and needs such as design specifications, purchasing, regulation or contractual agreements. To conform to WCAG 2.1, it is necessary to satisfy the success criteria guaranteeing that there is no content that violates them (see Table1). The evaluation of success criteria is performed in terms of three levels of conformance (see Table1), in such a way one of the three is met in full: • Level A (lowest): The web page satisfies all the Level A Success Criteria, or conformance to an alternate version is provided. • Level AA (medium): The web page satisfies all the Level A and Level AA Success Criteria, or a Level AA alternate version is provided. Table 1: Web Content Accessibility Guidelines WCAG 2.1 (Adapted of [22]) PRINCIPLE / Accessibility guidelines WCAG 2.1 WCAG 2.1 Accessibility criterion Accessibility level PERCEPTIBLE: Information and user interface components must be presentable to users in ways they can perceive. 1.1 Text alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language. 1.1.1 Non–textual content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below A 1.2 Based on mean time: Provide, alternatives for time–based means of communication. 1.2.1 Audio–only and video–only (Prerecorded): For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled. A • Level AAA (highest): The web page satisfies all the Level A, Level AA and Level AAA Success Criteria, or a Level AAA alternate version is provided. In addition to evaluate the accessibility, WAI also provides resources that support and help in its assessment. In previous work [ 14 ], authors presented a methodology for evaluating the accessibility and usability of OER sites. This methodology is based on the WCAG. This methodology reveals that these guidelines can be represented as an OVM model. In this work, we are going to use the WCAG 2.1 and before their OVM representation, we have made a synthesis of their principles, accessibility guidelines and success criteria definitions and their accessibility level in a Table (see an excerpt of this in Table1, see the complete specification in the supplementary material1). 3 RELATED WORKS There are many approaches that define how to specify NFR in SPL, some of them are based on Feature Models (FM) and include NFR with an extended FM, as the work of Benavides et al. [ 1 ]. This work proposes to model SPL considering both, functional and nonfunctional features. FM are extended with attributes [7], and their relationships together with dependencies relationships between features [ 18 ]. So, functional requirements and NFR coexist in the 1https://bit.ly/2JR9PyN Accessibility Variability Model: The UTPL MOOC Case Study SPLC ’19, September 9–13, 2019, Paris, France same model. The works of Chavarriaga et al. [ 4 ], [ 3 ] propose operations to address the need of combining FMs. This work is based on the premise that in the manufacturing sector, it is required the use of different FMs for specifying the domain variability and the standard and regulations variability of manufactured products, such as transformers of power networks. On the other hand, there are other approaches based on UML models, the work of González-Huerta et. al [ 8 ] presents a MDD approach that allows the identification and representation of quality NFR for SPL. The approach makes use of a multimodel to express through a quality NFR metamodel. This work takes a step forward by defining a metamodel that allow the specification of any NFR, specifically focusing on quality. However, this work presents the quality requirements models as UML class models conformed to the metamodel instead of using variability models. The work of Nguyen et. Al. [ 11 ] consists of the integration of: a) the extension of Product Line UML-Based Software Engineering (PLUS) [ 11 ] to analyze and quantify NFR, and b) a reasoning engine. This integration constitutes a unified and systematic framework for analysis modeling of NFR in SPLs. Another approach is [ 23 ], where a systematic approach for modelling quality attributes in feature models and making quality-aware configurations is defined. This approach is implemented by a three-phase process: (1) Identify and represent the quality attributes in the feature models, (2) Measure the interdependencies between the features and the quality attributes, (3) Configure a product considering the quality. There are other approaches based on Orthogonal Variability Models (OVM) for modelling NFR. Roos-Frantz et. al [ 15 ] present an approach for analyzing the quality of an SPL. This work represents the variability with an OVM that it is mapped with the quality model to associate the quality information and allow the constraints verification. In addition, authors have developed the tool FaMa-OVM to support the modelling of OVM [ 1 ], [ 16 ]. These related works vary in the model that they use for specifying variability, but they also have points in common. The works of González-Huerta [ 8 ] and Roos-Frantz [ 15 ] set out the need of managing quality as an orthogonal aspect. However, they do not provide guidelines about the non-functional features that should be considered to deal with a specific NFR. González-Huerta [ 8 ] proposes a NFR metamodel and Roos-Frantz [ 15 ] proposes quality attributes associated to the OVM, where features or attributes that are non-related with the NFR can be defined. So, it is necessary to have control not only of the syntax, but also the semantics by guiding the user in which features and attributes are related to a specific NFR or not. Therefore, we propose non-functional specific OVM to guarantee the alignment between the non-functional features and the NFR standards and guidelines, in particular the accessibility OVM. As a result, this work provides a guidance by establishing which are the accessibility features that have to be considered. This accessibility OVM is complementary to Functional OVM, as the work of Chavarriaga et al. [ 4 ], [ 3 ] propose for specifying the variability of manufactured products with multiple FM. 4 ACCESIBILITY OVM In this paper, we present the accessibility VM using an OVM representation. OVM provide a cross-sectional view of the variability across all product line artefacts [ 13 ] by interrelating the variability with base models such as requirement models, design models, component models, and test models. The traceability between OVM and the different types of base models is established through dependencies [ 15 ], which allow us to know the impact and implementation of the variable features into software products. Accessibility OVM has been specified based on the standard WCAG 2.1 (see section 2.1). The principles and guides are modelled as variation points (VP) or variants; whereas the success criteria are modelled as variants (V). Figure 1 represents the main variability points of the Accessibility OVM and their variants, and the variants of the Perceivable variability. It is not feasible to illustrate all the VP and variants due to space reasons (see complete model in the supplementary material 2 ). In the Accessibility OVM, every variability is optional because it is an option to make a website accessible, and also vary to what extent accessibility is implemented (see Figure 1 and the supplementary material). The accessibility OVM is reusable for any family related to web contents, since it is based on the WCAG standard. This accessibility OVM defines those criteria and principles of the standard to guarantee the standard compliance and its reusability. The OER SPL has a large functional OVM, where the courses, teachers, and content management conform the core of the SPL and vary the different ways of providing these common functionalities, in addition to extra functionalities. Figure 3 illustrates an excerpt of the SPL, just to illustrate the relationship between the functional and non-functional variants from the functional and accesibility OVM, respectively. For example, the OER content is related the Perceivable principle, therefore some variants of the VP Content Management are related with the variants of the Perceivable VP (see Figure 3). In addition, the quality model to measure the accessibility of products has been defined. The quality model is presented in Table 2. Each quality attribute is defined by an identifier, a name, a domain, a principle/guide, an accessibility level and the formula to calculate the value. The quality attributes are related with their corresponding variability points or variants of the Accessibility OVM (see Figure 2 and it’s supplementary material 3 ). As shown in Table 2, the accepted values for attributes associated to variants may be from 0 to 3. The standard WCAG 2.1 categorizes its success criteria between A, AA, or AAA. The formula to obtain the values for variants are: IF (A) = 1, IF(AA)=2, IF(AAA)=3, see the examples in Quality Information of Figure 2 1.2.1, 1.2.5, 1.2.7, respectively. Some variants are constrained by another VP, for example, the variant V.1.3 Adaptable (see Figure 1). In this case the formula depends on the VP formula. Therefore, in order to support the constrained variants, the domain is always established between 0 and the maximum value that the established by the accessibility level (see Table 2 and Figure 2), that is 0 to 3. On the other hand, the VP formula is the average of its variants. Once the Accessibility OVM is configured the value of the formulas are calculated. The defined quality model results will provide us information about the accessibility degree of a specific product and for each of the accessibility principle. If the result is between 0 and 1, the product will be labelled with an A accessibility, if the result is between 2https://bit.ly/2YFt9Dn 3https://bit.ly/2HDyl3U SPLC ’19, September 9–13, 2019, Paris, France Germania Rodriguez, Jennifer Pérez, and David Benavides VP1 Perceivable VP VP1.2Time VP V1.1 Text Alternative V V1.2 Timing Media V V1.3 Adaptable V V1.4 Distinguishable V [4…4] 1.2.1 Pre–recorded audio and video V 1.2.2 Captions (Prerecorded) V 1.2.3 Audio Description or Media Alternative V 1.2.4 Captions for Audio V 1.2.5 Audio description for V 1.2.6 Sign Language V 1.2.7 Extended Audio Description V 1.2.8 Media Alternative V 1.2.9 Audio-only (Live) V VP1.3 Adaptable VP 1.3.1 Structure info and relationships V 1.3.2 Meaningful Sequence 1.3.3 Sensory Characteristics 1.3.4 Orientation 1.3.5 Identify Input Purpose 1.3.6 Identify Purpose V V V V V VP1.4 Distinguishable VP 1.4.1 Use of Color V 1.4.2 Audio Control V 1.4.3 Contrast (Minimum) V 1.4.4 Resize text V 1.4.5 Image of text V 1.4.6 Contrast (Enhanced) V 1.4.7 Low or No Background Audio V 1.4.8 Visual Presentation V 1.4.9 Images of Text (No Exception) V 1.4.10 Reflow V 1.4.11 Non-text Contrast V 1.4.13 Content on Hover or Focus V 1.4.12 Text Spacing V [9…9] [6…6] [13…13] VP2 Operable VP VP2.2 Enough Time V V2.3 Seizures and Physical Reactions V V2.4 Navigable V V2.5 Input Modalities V [5…5] VP2.1 Keyboard Accessible V VP3 Understandable VP V3.1 Readable V3.2 Predictable V V3.3 Input Assistance V [3…3] V VP4 Robust VP V4.1 Compatible V [1…1] VP5 Conformance VP V5.2 Conformance Requirements V V5.3 Conformance Claims (Optional) V 5.4 Statement of Partial Conformance - Third Party Content V 5.5 Statement of Partial Conformance - Language V [5…5] 5.1 Interpreting Normative V VP1.1 Alternative Text 1.1.1 Non-text Content [1…1] VP V Figure 1: Accessibility OVM (Excerpt) Accessibility Variability Model: The UTPL MOOC Case Study SPLC ’19, September 9–13, 2019, Paris, France VP1 Perceivable VP V1.1 Text Alternative V V1.2 Timing Media V V1.3 Adaptable V V1.4 Distinguishable V VP1.2Time VP VP1.3 Adaptable VP VP1.4 Distinguishable VP Id: VP1 Name: Perceivable Domain: Integer (0 to 58) Principle: N/A Level of Accessibility: A,AA,AAA Formula: Average (1.1, 1.2, 1.3, 1.4) Id: V1.1 Name: Text Alternative Domain: Integer (0 or 1) Principle: Perceivable Level of Accessibility: A Value: 1 Id: VP1.2 Name: Time based media Domain: Integer (0 to 2,2) Principle: Perceivable Level of Accessibility: A, AA, AAA Formula: Average (1.2.1.. 1.2.9) Id: VP1.3 Name: Adaptable Domain: Integer (0 to 2,2) Principle: Perceivable Level of Accessibility: A, AA, AAA Formula: Average (1.3.1…1.3.6) Id: VP1.4 Name: Distingishable Domain: Integer (0 to 2,2) Principle: Perceivable Level of Accessibility: A, AA, AAA Formula: Average (1.4.1…1.4.13) ACCESSIBILITY OVM QUALITY MODEL [4…4] V1.2.1 Pre–recorded audio and video V1.2.2 Captions (Prerecorded) V1.2.3 Audio Description or Media Alternative V1.2.4 Captions for Audio V1.2.5 Audio description for V1.2.6 Sign Language V1.2.7 Extended Audio Description V V1.2.8 Media Alternative V1.2.9 Audio-only (Live) [9…9] Id: VP1.2 Name: Time based media Domain: Integer (0 to 2,2) Principle: Perceivable Level of Accessibility: A, AA, AAA Formula: Average (1.2.1…1.2.9) Id: V1.2.1 Name: Pre–recorded audio and video Domain: Integer (0 or 1) Principle: Perceivable Level of Accessibility: A Value: 1 Id: V1.2.2 Name: Captions (pre-recorded) Domain: Integer (0 or 1) Principle: Perceivable Level of Accessibility: A Value: 1 Id: V1.2.4 Name: Captions for audios Domain: Integer (0 or 2) Principle: Perceivable Level of Accessibility: AA Value: 2 Id: V1.2.6 Name: Sign language Domain: Integer (0 or 2) Principle: Perceivable Level of Accessibility: AA Id: V1.2.8 Name: Media alternative Domain: Integer (0 or 3) Principle: Perceivable Level of Accessibility: AAA Value: 3 Id: V1.2.3 Name: Audio description or Media alternative Domain: Integer (0 or 1) Principle: Perceivable Level of Accessibility: A Value: 1 Id: V1.2.5 Name: Audio description for Video Domain: Integer (0 or 2) Principle: Perceivable Id: V1.2.7 Name: Extended audio Domain: Integer (0 or 3) Principle: Perceivable Level of Accessibility: AAA Value: 3 Id: V1.2.9 Name: Audio only Domain: Integer (0 or 3) Principle: Perceivable Level of Accessibility: AAA V V V V V V V V VP1.1 Alternative Text VP V1.1.1 Non-text Content V Id: V1.1.1 Name: Non-text content Domain: Integer (0 or 1) Principle: Perceivable Level of Accessibility: A Value: 1 Id: V1.1 Name: Alternative Text Domain: Integer (0 or 1) Principle: Perceivable Level of Accessibility: A Value: 1 Figure 2: Accessibility OVM and quality model relationships 1 and 1,38, the product will be labelled with an AA accessibility, and finally, if the result is between 1,39 a 1,96 the product will be labelled with an AAA accessibility. It is important to emphasize that this accessibility OVM together the defined quality model can be used by web designers to evaluate existing web sites or knowing the accessibility degree during requirements elicitation. This is a valuable information, since they SPLC ’19, September 9–13, 2019, Paris, France Germania Rodriguez, Jennifer Pérez, and David Benavides Content Management VP V.1 Create Content V Perceivable VP Funtional OVM Accessibility OVM [5…5] 1.1.1 Non-Text Content V V1.2 Timing Media V V1.3 Adaptable V V1.4 Distinguishable V V.2 Read Content V V.3 Update Content V V.4 Delete Content V V.5 Search Content V V.6 Share Content V V.7 Customize Content V V.8 Content Harvest V V.9 Advanced Search V V.10 Ranking Content V [4…4] Figure 3: Functional OVM and Accessibility OVM relationships Table 2: Quality information Model Name Label Description Identifier Id Criteria/principle/guide number in the standard WCAG 2.1 Name Name Criteria/principle/guide Name in the standard WCAG 2.1 Domain Domain Range of acceptable values for measure the criteria/principle/guide Principle Principle Accessibility principle or guide that the variant is related to. Accesibility Level Accesibility Level Accessibility level for each criteria: A, AA, AAA Value / Formula Value / Formula Variants: Percentages assigned by level of Accessibility A = 0.65%, AA = 1.31%, AAA = 1.96% VP: The value is obtained by adding the percentages of the associated variants, so that the total sum of all the variants of the LMO is 100% are on time to correct requirements if they realize that the product does not have the desirable accessibility degree. So, they can select more features or more valuable features in advance for being implementing by following guidelines to improve accessibility [ 14 ]. 5 ACCESIBILITY OVM INTO PRACTICE: THE UTPL MOOC Evidence of the viability of the accessibility OVM can be obtained by putting the model into practice in a real-life setting. Therefore, we have conducted a case study. 5.1 Case Study Description As a first experience, this work has been applied the accessibility OVM of a web site to evaluate its accessibility degree. Instead of developing a web site from scratch, we have derived the configuration of an existing MOOC [24] from the SPL. Specifically, the derived product is the MOOC of the Universidad Técnica Particular de Loja (UTPL) [7]. The UTPL MOOC has 12 available courses and it is composed of 100 web pages that have many functionalities such as content management, user management, searches, user interface facilities etc. 5.2 Research Objective As the completeness of the accessibility features is already guaranteed by the fact that they are defined by standard/standardized guidelines, we know that the accessibility OVM considers the required features for modelling accessibility in web content applications. Therefore, in this initial pilot case study, we focused on the accessibility measurement to assist the engineer during the derivation of a product from the SPL, and thus, obtaining a product that maximizes the accessibility. In this pilot case study, the main two questions to be answered through the case study analysis can be formulated as follows: •RQ1. Are the accessibility OVM and its quality information model able to provide a measure of the accessibility of the system from the derivation of a product? •RQ2. Is able this mechanism to recommend which features should be selected during the derivation to improve the accessibility of a previous derived product? 5.3 Reporting RQ1. The first step was to configure the product of the MOOC UTPL from the OER SPL by deriving during the application engineering the functional and accessibility configuration. In particular, the derivation was performed from the main page and some MOOC random pages. The result of this derivation of the Accessibility Model is presented in Figure 4. From the selected variants of the Accessibility OVM illustrated in Figure 4, the quality attribute information is calculated during the configuration phase. Table 3 illustrates the accessibility evaluation results after the application engineering for this product. The values for each variability point are obtained applying the formulate associated to it which is the average of the success criteria value for example the VP1.3 is the result of average of their variants V1.3.1, V1.3.2, V1.3.3, V1.3.4, V1.3.5, V1.3.6 in the study case none of these variants is present in the case of studies for that the VP1.3 value is 0. A total average of 0,18 means that it has an A accessibility level of average, but not all the variants of A are implemented. This is an evidence that the proposed model allows providing a measure and a label of accessibility to a specific product and to reveal that the site should be improved. RQ2. As a second exercise and based on previous works and our experience in the area [ 6 ], we have used the model to configure a product by selecting the minimum desirable accessibility features that a product of this family should have to be accessible. To that end, we have configured the product by selecting the variants presented in Figure 5, and we have obtained the evaluation presented in Table 4. This product may be used as a reference in the area, to reach this minimum value of accessibility level, i.e. an average AA. As a result, it may help engineers recommending including the features that are desired features to improve accessibility. For example, in our case it is recommend to improve the Perceivable Accessibility Variability Model: The UTPL MOOC Case Study SPLC ’19, September 9–13, 2019, Paris, France 1.4.1 Use of color 2.1.1 Keyboard 3.1.1 Language of Page 1.4.3 Contrast minimum 2.1.4 Character Key Shortcuts 1.4.4 Resize text 2.4.2 Page Titled 2.4.5 Multiple Ways 2.4.6 Headings and Labels 2.4.7 Focus Visible 2.4.10 Section Headings Figure 4: Current UTPL MOOC configuration Table 3: Accessibility Evaluation Results of the UTPL MOOC Variability Point Average VP1 Perceivable 1.00 VP1.1 Text Alternative 0.00 VP1.2 Time based media 0.00 VP1.3 Adaptable 0.00 VP1.4 Distinguishable 0.38 VP2 Operable 0.26 VP2.1 Keyboard Accessible 0.50 VP2.2 Enough Time 0.00 VP2.3 Seizures and Physical Reactions 0.00 VP2.4 Navigable 0.80 VP2.5 Input Modalities 0.00 VP3 Understandable 0.05 VP3.1 Readable 0.16 VP3.2 Predictable 0.00 VP3.3 Input Assistance 0.00 VP4 Robust 0.33 VP4.1 Compatible 0.33 Total 0,18 principle by including 22 new features such as: Non-text content, Pre–recorded audio and video, Pre–recorded audio and video, etc.; 7 new features to address the Operable principle; 10 new features in the Understandable principle; and finally, to address the Robust principle that it is missing in the current version of the product. 6 CONCLUSION AND FUTURE WORK This paper presents how to specify the variability of NFR standardized by standard committees using specific OVM, specifically the accessibility OVM of the web content accessibility guides (WCAG) 2.1 W3C recommendation. This contribution allows one to guarantee following the WCAG and having a measure of their compliance, since the quality model associated to them provide this information. In addition, this paper demonstrates its adoption by presenting the Accessibility OVM and its application in the Open Educational Resources (OER) SPL by deriving and measuring a specific product, the UTPL MOOC. Finally, it is important to emphasize that this work also provides a product model with the minimum desirable properties to consider a product accessible enough. This product model in terms of accessibility may be a guide to reach or exceed for those products accessibility-aware. This work is the beginning Table 4: Accessibility desirable feature level for MOOCs sites Variability Point Average VP1 Perceivable 1.47 VP1.1 Text Alternative 1.00 VP1.2 Time based media 1.77 VP1.3 Adaptable 1.66 VP1.4 Distinguishable 1.46 VP2 Operable 1.04 VP2.1 Keyboard Accessible 1.50 VP2.2 Enough Time 0.33 VP2.3 Seizures and Physical Reactions 1.00 VP2.4 Navigable 1.20 VP2.5 Input Modalities 1.17 VP3 Understandable 0.74 VP3.1 Readable 0.50 VP3.2 Predictable 0.40 VP3.3 Input Assistance 1.33 VP4 Robust 1.33 VP4.1 Compatible 1.33 Total 1,16 of a wide variety of future work, from automatizing the defined process, to extend the case study and to specify more Non-Functional Specific OVM for other standards. ACKNOWLEDGEMENTS This work has been partially funded by by Secretaria Nacional de Ciencia y Tecnología (SENESCYT) Ecuador, the Project CROWDSAVING (TIN2016- 79726-C2-1-R), the EU FEDER program, the MINECO project OPHELIA (RTI2018-101204-B-C22); the TASOVA network (MCIU-AEI TIN2017-90644- REDT); and the Junta de Andalucia METAMORFOSIS project. REFERENCES [1] David Benavides, Pablo Trinidad, and Antonio Ruiz-Cortés. 2005. Automated Reasoning on Feature Models. Seminal Contributions to Information Systems Engineering 01 (2005), 361–373. https://doi.org/10.1007/978-3-642-36926-1{_}29 [2] Giorgio Brajnik. 2008. A comparative test of web accessibility evaluation methods. (2008), 113. https://doi.org/10.1145/1414471.1414494 [3] Jaime Chavarriaga, Rubby Casallas, and Viviane Jonckers. 2017. Implementing Operations to Combine Feature Models: The Conditional Intersection Case. Proceedings - 2017 IEEE/ACM 2nd International Workshop on Variability and Complexity in Software Design, VACE 2017 (2017), 41–47. https://doi.org/10.1109/VACE.2017.2 [4] Jaime Chavarriaga, Carlos Rangel, Carlos Noguera, Rubby Casallas, and Viviane Jonckers. 2015. Using multiple feature models to specify configuration options for electrical transformers. (2015), 216–224. https://doi.org/10.1145/2791060.2791091 [5] Paul Clements and Linda Northrop. 2002. Software Product Lines: Practices and Patterns. Addison-Wesley. [6] Krzysztof Czarnecki. 2002. Generative Programming : Methods , Techniques ,. (2002), 351–352. [7] Krysztof Czarnecki and Ulrich Eisenecker. 2000. Generative Programming: Methods, Tools, and Applications. Addison-Wesley Professional. 864 pages. [8] Javier González-Huerta, Emilio Insfran, Silvia Abrahão, and John D. McGregor. 2012. Non-functional requirements in model-driven software product line engineering. December (2012), 1–6. https://doi.org/10.1145/2420942.2420948 [9] ISO 25010. [n. d.]. International Standard, Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models. Technical Report. [10] ISO/IEC/IEEE 29148. 2011. International Standard, Systems and software engineering — Life cycle processes — Requirements engineering. Technical Report. [11] Quyen L Nguyen. 2009. Non-functional requirements analysis modeling for software product lines BT - 2009 ICSE Workshop on Modeling in Software Engineering, MiSE 2009, May 16, 2009 - May 24, 2009. (2009), 56–61. https: //doi.org/10.1109/MISE.2009.5069898 SPLC ’19, September 9–13, 2019, Paris, France Germania Rodriguez, Jennifer Pérez, and David Benavides 1.1.1 Non text content 2.1.1 Keyboard 3.1.1 Language of Page 1.2.1 Pre–recorded audio and video 2.1.2 No keyboard trap 3.1.2 Language of Parts 1.2.2 Captions (pre-recorded) 2.1.3 Keyboard (No exception) 3.2.1 On Focus 1.2.3 Audio description or Media alternative 2.1.4 Character Key Shortcuts 3.2.2 On input 1.2.4 Captions for audios 2.2.1 Timing Adjustable 3.2.3 Consistent Navigation 1.2.5 Audio description for Video 2.2.2 Pause, stop, hide 3.2.4 Consistent Identification 1.2.6 Sign language 2.3.3 Animation from Interactions 3.3.1 Error Identification 1.2.8 Media alternative 2.4.1 Bypass Blocks 3.3.2 Labels or Instructions 1.2.9 Audio only 2.4.2 Page Titled 3.3.3 Error Suggestion 1.3.1 Structure info and relationships 2.4.3 Focus Order 3.3.4 Error Prevention (Legal, Financial, Data) 1.3.2 Meaningful sequence 2.4.4 Link Purpose (In Context) 3.3.5 Help 1.3.3 Sensory characteristics 2.4.5 Multiple Ways 1.3.4 Orientation 2.4.6 Headings and Labels 4.1.1 Parsing 1.3.5 Identify input purpose 2.4.7 Focus Visible 4.1.2 Name, Role, Value 1.3.6 Input purpouse 2.4.9 Link Purpose (Link Only) 4.1.3 Status Messages 1.4.1 Use of color 2.5.3 Label in Name 1.4.2 Audio Control 1.4.3 Contrast minimum 1.4.4 Resize text 1.4.5 Images of text 1.4.6 Contrast Enhanced 1.4.10 Reflow 1.4.11 Non-Text contrast 1.4.12 Text spacing 1.4.13 Content on hover or focus Figure 5: The minimum desirable Accessibility in a MOOC configuration [12] International Standard Organization. 1998. ISO 9241-11 Guidance on usability. Technical Report. [13] Klaus Pohl, Günter Böckle, and Frank J. van der Linden. 2005. Software Product Line Engineering Foundations, Principles and Techniques. Springer. [14] G. Rodríguez, J. Pérez, S. Cueva, and R. Torres. 2017. A framework for improving web accessibility and usability of Open Course Ware sites. Computers and Education 109 (2017). https://doi.org/10.1016/j.compedu.2017.02.013 [15] Fabricia Roos-Frantz, David Benavides, Antonio Ruiz-Cortés, André Heuer, and Kim Lauenroth. 2011. Quality-aware analysis in product line engineering with the orthogonal variability model. Software Quality Journal 20, 3-4 (2011), 519–565. https://doi.org/10.1007/s11219-011-9156-5 [16] Fabricia Roos-Frantz, José A Galindo, David Benavides, and Antonio Ruiz Cortés. 2012. FaMa-OVM: a tool for the automated analysis of OVMs. 16th International Software Product Line Conference, {SPLC} ’12, Salvador, Brazil - September 2-7, 2012, Volume 2 (2012), 250–254. https://doi.org/10.1145/2364412.2364456 [17] Ian Sommerville. 2016. Software Engineering. Pearson Education. [18] Detlef Streitferdt, Matthias Riebisch, and Ilka Philippow. 2003. Details of Formalized Relations in Feature Models Using OCL Detlef Streitferdt. In Proceedings of 10th IEEE International Conference on Engineering of Computer–Based Systems (ECBS 2003). 45–54. [19] UTPL. 2019. UTPL MOOC. (2019). https://mooc.utpl.edu.ec/ [20] W3C. [n. d.]. Web Accessible Initiative. ([n. d.]). https://www.w3.org/WAI/ [21] W3C. [n. d.]. World Wide Web Consortium. ([n. d.]). [22] W3C. 2018. Web Content Accessibility Guidelines (WCAG) 2.1. (2018). https: //www.w3.org/TR/WCAG21/ [23] Guoheng Zhang, Huilin Ye, and Yuqing Lin. 2014. Quality attribute modeling and quality aware product configuration in software product lines. Software Quality Journal 22, 3 (2014), 365–401. https://doi.org/10.1007/s11219-013-9197-z