Fixing Accessibility Issues in Open-Source Teaching Repositories

In the LINTI, New Information Technologies Research Laboratory at the Computer Science School, in the National University of La Plata, it is being developed a project that involves the integration of the repository, implemented using DSpace, with different tools and platforms used in academic tasks. Accessibility is a process that cuts across all software development stages, so when using a free software product it is important to evaluate it in order to correct faults if it ́s necessary. This article describes a DSpace repository accessibility validation, using screen readers for manual test, automatic validation with software tools and experimental test with users with and without disabilities. The evaluation involves the proper basic functions and the implemented extensions. The original DSpace software was extended through the integration with different tools and platforms, such as Moodle LMS, the library management system called Meran, file management services like DropBox and GoogleDrive and the social network Facebook. The tools used during accessibility evaluation were Examinator, Google ChromeVox and one entirely implemented in the LINTI, called SiMor. The experimental tests were made with blind and deaf persons, most of them college students. All the validation results are detailed using tables and graphs, where it can observe the measured values. It is also described the changes that was necessary to carry out in the repository to improve the user experience and ensure Web service accessibility.


Introduction
The main universities of several countries have incorporated into their educational offer e-learning programs for professional training that make use of ICTs, which allow flexibility in time and space, in order to integrate more people into the teaching-learning processes. These programs consume and generate content in digital format that can be used by other programs, systems or organizations that share common objectives. However, the maximum use of resources is achieved when ubiquity is its main feature, when systems intercommunicate and share resources in an efficient and transparent way for multiple users. With this goal in mind, the education sector is committed to the dissemination and reuse of open objects as a key element for interoperability and resource concentration in a standard, shared and organized way. The concept of Open Educational Resources (OER) emerged with a movement that initiated the development of Open Source Software. In 2002, UNESCO became the host of the global discussion around this initiative and holds an international discussion forum to serve as a laboratory of ideas and a catalyst for international cooperation. The possibility of storing the resources generated in the framework of e-learning as OERs in open access repositories increases the availability of the material even further, allowing greater flexibility in learning and extending people's capacities to collaborate and share knowledge. For this reason, integrating the different information systems involved in the field of distance education is extremely important and challenging. Following this line, for a number of years, a project has been developed at LINTI, the Laboratory of Research in New Information Technologies, which aims to integrate different platforms and tools that are used within the academic field, as well as communicate with widespread social networks. The project includes not only the creation of the repository to host

Context
It was in the early 1990s that the first initiatives to create archives or open repositories of specialized documents arose, in order to facilitate access to content up to then only available to those who could afford it. Since then, the movement has grown and evolved globally, and there are more and more academic institutions that support the creation of repositories or initiatives of this type [10]. The purpose of a repository is to manage digital resources, understanding the resource as the representation of a real object from the metadata that describe it and allows access, distribution and dissemination, to preserve them. The worldwide trend of publishing the production of academic institutions through open access repositories is constantly growing, as can be seen in OpenDOAR [11], the authorized directory of open access academic repositories. As previously mentioned, DSpace is one of the most widely used free software for the implementation of digital repositories. It provides tools for the administration of digital collections, as well as multiple tools and functionalities for preservation, metadata management, search and visibility of elements and management of authors, typical of a digital repository. Fig. 2 shows that Dspace is the most used software in the world for the management of repositories. The construction of a digital repository in the Computer Science School, using material that complements the collection of the school library, includes the analysis of the information to be stored along with the cataloging details of the same. In our case, the material to be incorporated includes content generated by both teachers and students, as well as institutional videos and academic reports. The integration of the repository with other educational resource management platforms such as libraries, virtual learning platforms, other open source virtual repositories, cloud services and social networks is fundamental to encourage the use of the repository, collaborating with new objects and offering facilities for its later management.
The Computer Science School of the National University of La Plata currently has more than 4,000 students and 300 teachers [12]. The Moodle Learning Management System is a de facto standard of e-learning platforms. It has been used as a complement to face-to-face classes and entirely virtual courses since more than 9 years. It allows to share educational material generated by the teachers in multiple formats, and to generate discussion forums and collaborative activities like Wikis. In addition, it allows the delivery of tasks in different ways, such as uploading files or text online from instructions published by the teacher and delivery dates guidelines. From this platform the teacher corrects the task, assigns a note and makes a commentary on it, among other possibilities. Moodle has more than 80,000 registered sites. It is free software and translated into more languages.
Moodle has been used in the School for more than 9 years, in courses that complement classroom classes [13], Extension courses for the community [14] and postgraduate courses [15]. It has a great amount of academic material generated by more than 14,000 users and stored in more than 500 courses. The volume of material generated in this period by students and teachers is very significant [16].
There is also a set of videos on the different events that are carried and on the activities developed. Currently, the School it has its own channel on YouTube [17], with more than 80 videos published on the activities carried out in the School in recent years.
At LINTI, we have been working on the topic of web accessibility for many years, studying the existing norms and working together in raising awareness of the current issues for the disabled on the Web. In relation to this, a distance course on web accessibility, available at https://cursos.linti.unlp.edu.ar/course/index.php?categoryid=17, has been given for more than 5 years, and is intended at the general public, computer scientists and other professionals that are linked to this topic. In addition, extension projects have been developed on this subject, approved by the National University of La Plata, and aiming at multidisciplinary collaboration for the formation of the principles of web accessibility, its advantages, its scope and responsibilities according to the different roles involved in web development. The knowledge generated is also transferred to the development of accessible software of the UNLP, such as the SIPU Course Pre-Enrollment System [18], which allows to manage more than 20,000 average university enrollments per year, with over 600 applicants reporting some type of disability only in the past year, and the UNLP Schools Pre-Enrollment System [19], which has infinite scrolling photo banners and other resources that enrich the presentation and is accessible.

Description of the digital repository
The repository is being implemented with the DSpace platform, which is open source, provides tools for the management of digital collections, and is commonly used to manage institutional repositories. It was released in 2002, as a product of an alliance between HP and MIT. It was released under a BSD license that allows users to customize or extend the software as needed. DSpace is structured in communities and collections, the latter being where the resources are stored.
In the beginning, in the implementation of the repository, all the material is organized in the communities, course materials ("Material de cátedras"), Undergraduate Theses ("Tesinas de grado") and Institutional videos ("Videos institucionales"). The Course Materials Community contains two sub-communities for storing academic content and grade level student work for various courses offered by the School. The Institutional Videos community will contain audiovisual material related to events organized within the framework of the School. It is foreseen in the short term to include also the undergraduate final papers, and later, articles published by teachers and researchers of the academic unit.
In the implementation of the repository, the interface design was completely modified as a form of customization to adapt it to the characteristics of the institution and to incorporate the functions of communication with other systems. In this way, both the initial screen and those that show the items stored in each of the collections were modified to include the new functionalities.
The project began with the integration of the repository with the virtual learning platform Moodle, so as to be able to establish a bidirectional communication between both platforms. In the first instance, the communication was carried out in order to consult and transfer elements from DSpace and to include them within the content of a course [20]. In a second stage, a specific module was implemented that allows semi-automatic publishing of material generated by the students through deliveries made in the Tasks ("Tareas") module. The possibility of having this method of publication encourages teachers who manage their courses in the educational platform to publish the works delivered by their students in one or several external repositories, since they do not need to know the interface or way of access to them [21].
In subsequent stages, communication functions with existing services and tools on the Internet were incorporated in order to enhance the services of the repository. Communication with Cloud, DropBox and Google Drive file management services was achieved, allowing users to save files by simply logging into the preferred file service. This communication provides greater flexibility for storing information of interest contained in the repository in work spaces. The repository was also integrated with the social network Facebook, to allow sharing and recommending a particular resource. Currently, it is a very common habit among young people to recommend and share with their friends different types of material such as videos, photos, posters, etc. The integration of this functionality within DSpace tries to take advantage of these habitual practices so that the content achieves a greater diffusion [22].

How to Test the Accessibility of a Tool
As mentioned above, verifying accessibility is a process that transcends all stages of software development and configuration and customization of tools. It is very important to validate accessibility standards on websites and applications, especially those that are available for public use, such as the recent validation on Homestay websites in Malaysia, by using an automated evaluation tool (Achecker) and Web Content Accessibility Guidelines (WCAG) 2.0 [23]. Act 26,653 promulgated in Argentina in 2010, which indicates that all websites belonging to public bodies must be accessible, complying with the WCAG guidelines for web content, allows a greater number of people to have access to available information on the Internet. Based on this legislation, in our country we began to carry out evaluations of websites using different tools, such as the universities websites accessibility evaluation in Argentina, in which 24 institutions were considered and evaluated [24]. The construction of web pages and the implementation of tools that meet the standards of accessibility is a responsibility that must always be present in every person who fulfills these functions. Within the university context, the different actors that participate --teachers, students, technicians, etc provide a particular vision of accessibility, and in their function each has a responsibility [25]. In particular, in the case of repositories containing open resources, an important usability aspect is related to the material search process, since it can be time-consuming and discourage resource use [26]. The creation of accessible educational resources or the adaptation of tools used in the academic field to be accessible not only encourages good educational policies, but also contributes to raising awareness on disability and makes it possible to comply with the regulations of the country [27].
At present, there is a set of programs that serve to validate compliance with accessibility standards set by the WCAG. Some of these programs, called validators, inspect web pages and analyze the level of accessibility they meet [28]. Although validators are important for detecting many accessibility issues, tests should be complemented with manual verifications and testing with users. In turn, it is critical that developers understand how people interact with the site. For example, trying to use a screen reader to understand the interaction between the site and people with visual disabilities. When talking about accessibility, it is important to take into account these two aspects related to the tests that must be performed in order for the sites to comply with the basic standards and in this way can be navigable using tools designed for people with disabilities, such as a screen reader. It should be noted that although there is a varied set of tools both to validate the sites and to assist users, some were analyzed and three of them were considered adequate and useful for the analysis to be performed. One of the tools, SiMor, was developed entirely at the Computer Science School, and is free for use and modification.
Within the validation tools, Examinator is designed to evaluate the accessibility of a website, based on some techniques recommended by the Web Content Accessibility Guidelines 2.0 for A, AA and AAA compliance criteria. Examinator evaluates a website, presenting an accessibility metric with an overall score between 1 and 10, together with the accessibility score for each type of disability possible, again rated between 1 and 10. In addition, a report is presented indicating which are the Accessibility errors present, indicating for each error the number of times it is found, the standards of accessibility it violates and the severity of the violation. It is a very intuitive and easy to use tool, as shown in Fig. 3. In this example, we can see the accessibility global score (7.2), of the UNESCO site, the time of the test and shortcuts to evaluation points results: excellent ("Excelente"), regular ("Regular"), bad ("Mal), very bad ("Muy Mal") and board ("Tablero"). For each evaluated rules and links, it is shown more information about the specific disabilities score. This tool allows the analysis of a sites with few pages. Google ChromeVox [29] is a browser-specific screen reader for Google Chrome, it is highly configurable since it can be used in different languages, and provides various keyboard shortcuts for the various functionalities. Like other screen readers, ChromeVox offers different alternatives to browse websites. These alternatives are based on the different modalities that the users have when visiting a site and are based on acquired habits, the search for a particular piece of information, or on the interest in learning more about a piece of information accessed. The most prominent alternatives related to navigation offer specific key combinations and are based on allowing to cross sections and the internal contents of them or to cross sections without accessing the subsections. It also offers alternatives in regards to being able to find the next element of a certain type, for example, through different keys it is possible to shift the focus of attention to the next link within the page, or to the previous heading. In case the user needs help with the commands, there is a menu which provides shortcuts and also provides information about the available commands.
This range of options provided by the tool are very important because they allow different users to navigate in a different way on the site, for example a user can search the links directly, another can navigate everything in extreme detail, using some of the commands already mentioned, while possibly other users perform simpler navigations using fewer keys.
Finally, the open source SiMor tool, developed entirely at LINTI, tries to gather distinctive features not present in the current validators, in order to facilitate the work of the web developer in creating content accessible for an inclusive web. SiMor is an intensive rule-based parser and its development is based on the initial specification of the W3C WCAG 2.0 rules. It is an accessible tool, allowing disabled users to use the validator in different sites. It has a fluid design and is optimized for all types of mobile devices.
This tool supports full validation of the site, i.e. once the validation process is activated, it does not do it only per page as the other validators do, but validates at the general level of the whole site. It includes complete details of the validation with information related to rules and elements evaluated, number of problems encountered, location of problems in the original code, and screen captures of each link analyzed. Fig. 4 shows the main screen of a SiMor user with a record of the sites being validated. The screen shows My sites ("Mis Sitios"), Total Sites ("Sitios en total") and HTML Validations ("Validaciones HTML"). For each site it is shown: Alias ("Alias"), URI ("URI"), Last Validation ("Última validación"), Progress ("Progreso"), Status ("Estado"). The button Add ("Agregar") is to add more sites to evaluate. It allows to perform a partial and configurable validation of the site, allowing to select with clear grammatical expressions the pages that the validator must skip to avoid the evaluation of the complete site. This is useful when reviewing a site after some modification since it avoids unnecessary evaluations that would slow down the analysis. Performing a continuous validation process, it allows the monitoring of validations. For this, SiMor requires the previous creation of a user account, which allows to see the development progress in aspects of accessibility. This means that the validations performed are not ephemeral, but are part of a continuous evaluation process, and comparisons can be made with previous validations. It is an educational tool, because every error detected in the code shows examples and suggestions on possible accessible alternatives that can solve it.
In addition to the tools used to validate accessibility features of websites, it is also convenient to perform manual tests with different groups of people, which allow us to evaluate different aspects of both usability and accessibility.
The tests consist of defining a set of objectives to be carried out, which are related to the functionality of the tool or website. From each pre-established objective, it is evaluated if it was completed, how easy it was to find the result and the time it took.

Tests Performed on the Repository
In order to have a complete accessibility assessment, it is essential to have usability tests with end users with and without disabilities. Performing these tests is indispensable, as mentioned in the W3C WCAG 2.0. The following sections describes the experience of performing automatic validations, manual validations with experts and tests with people with and without disabilities.

Using Validation Tools
In order to check the accessibility of the repository being constructed and begin to make any necessary modifications, the tools mentioned in the previous section were used. After using the Examinator validator, we obtained a detailed report of the errors presented by the platform and focused on some aspects of the main section that are confusing for navigation.
When we first evaluated the main section of the site using the Examinator tool, we obtained the report that appears in Table 1.
This report also shows that the site obtained a global score of 6.4 and with respect to each of the particular disabilities, the results were: • Total limitation to see: Score 6.1 (14 tests) • Severe limitation to see: Score 6.6 (13 tests) • Limitation of upper limbs: Score 6.6 (10 tests) • Limitation to understand: Score 6.2 (10 tests) • Limitations derived from age: Score 6.7 (12 tests) As a result of these, the various accessibility errors indicated by the tool were corrected. Following, we explain the implications of the errors, where they occurred, and how they were corrected.
The first error that indicates that there are 5 links with the same text but different destinations, occurs when there are links with the same name but different destination. This can happen when there is visual information that allows to deduce the destination of the link, which is out of reach for a visually impaired user. Within the repository, this error was found in the navigation bar, as can be seen in Fig. 5, where the lists according to different criteria had the same title when referring to local lists in the community or collection and to global lists. Error number 5, which indicates that there are 4 repeated values in the "id" attributes refers to elements with repeated identifiers. This is a problem since user agents use the identifiers to associate the various elements of the page, and their duplicity complicates to a great extent the work of user agents. This error was found in several elements of the repository where the "id" element was used to style it.
In addition to the tools used, another analysis of accessibility was performed based on previous knowledge and experiences of use of other platforms, which served to complement the accessibility information provided by the tools. The advantage of this type of analysis is that it is very simple and it can be done in short periods of time, not affecting the final development time and serving to improve accessibility simultaneously to the development of the system in question. The errors encountered with this approach led to rethinking and redoing the forms section.
Initially, the form of sending an item to a collection had more than 15 input fields, without any order or semantic criteria that grouped them, and because of this, it was difficult for the user to understand what information to enter. Another error found was that the only indication of a required field was an asterisk, which is not entirely clear an indicator. The next section shows the modifications made to improve this aspect.
As mentioned above, the SiMor tool was also used to obtain an additional validation. Successive site validations were performed and with the modifications described in the next section, the initial results were improved. The tool presents statistical graphs indicating the evolution of validation results for each version in terms of valid rules (in green), warnings (in yellow) and invalid rules (in red).
Regarding the repository, the validator analyzed 203 elements, of which 146 were valid elements, 50 were valid elements with warnings, and only 7 were invalid elements, resulting in 71% valid rules ("Reglas válidas"), 25% rules with warnings ("Reglas con Advertencias") and only 4% invalid rules ("Reglas inválidas"). The results of the validation performed with SiMor are shown in Fig. 6. The top of the screen shows the resulting percentages after the evaluation of the elements, and below is the HTML code analyzed and the corresponding page. At the bottom are the buttons for accessing reports in EARL and PDF format, which also respect the accessibility standards.
Same words for different functions.
For example, Authors of the global site or Authors of specific collections Figure 6: Results of the repository validation with SiMor. 71% valid rules ("Reglas válidas"), 25% rules with warnings ("Reglas con Advertencias") and only 4% invalid rules ("Reglas inválidas") After the evaluation it is possible to observe in detail a list of all the rules analyzed ("Detalles de la evaluación"), classified according to the categories mentioned. In each list, the label appears, with a description of the HTML element, the line where it appears, the rule ("Regla") according to the specific accessibility standard and the suggested actions ("Sugerencia"). A very important contribution of the tool is that each error detected shows original source code ("Código Fuente Original"), examples and suggestions on possible accessibility alternatives to solve it. Fig. 7 shows the detail of the infringed rule and a possible solution. Some of the rules that appeared as invalid are related to the need to associate mouse events with a keyboard equivalent. Other rules are focused on the organization of headings and titles. In both cases, the solution of these errors is simple with a small modification of the code.

Manual Validation
As mentioned in section IV, it is essential to perform manual validations that complement the automatic validations. The use of screen readers speed is this task and are used for manual verification by expert users and also by developers. For this we used the screen reader Google ChromeVox, which was extremely useful to detect also some shortcomings present in the repository in the navigation and search engines.
Manual validation with screen readers allows verifying semantic issues, such as the description of a particular image, tables features and relations between pages elements to facilitate site navigation and promoting its operability. This aspect is also complemented by the experimental tests, where some values are adjusted according to the perception and understanding of the users.
Browsing the site with the Google ChromeVox tool could find several difficulties regarding accessibility. The problems encountered have the common feature that they make it difficult for a blind user to interact with the site. The following are the accessibility errors encountered with the tool, and how they affect the user.
1. In the version of the repository search, which can be observed in Fig. 8, when the screen navigator is positioned in the search section ("Buscar en el repositorio"), it indicates to the user the presence of a texttype input field, followed by the search options and a button with the text go ("ir"). This design is confusing because the blind user may not identify it as a search form.

Invalid Rule ("Regla"
Simor's suggestions ("Sugerencia") to resolve an invalid rule 2. In addition, another point that was observed was that navigation of the site using the keyboard was quite tedious, for example, to position the screen reader in the main section it was necessary to navigate sequentially through the upper section of the site, as well as the side menu options. It also happened that in order to access certain functionalities inside the repository, several sections had to be crossed unnecessarily.
Both points can be solved by performing a refactoring of the search engine and including more links, as described in section 6 of the article.

Experimental Tests with Users with and without Disabilities
In addition to the automatic tests performed with the tools and the analysis based on the knowledge acquired on the subject of accessibility by expert users, a first manual verification was carried out with a blind person who has been working at LINTI with the manual accessibility checks of different platforms for more than 5 years. He is a Computer Science student with an expert level of PC use. The navigation consisted of asking him to navigate the repository and perform a series of basic functions, such as: • Identifying the purpose of the repository • Performing the search of two items • Listing the collections.
Most of the tasks were completed without difficulty, although the interaction with the search engines that appeared in the different sections and with some forms, which the validators had suggested correcting, was confusing. However, experimental tests with real users of the repository were still pending, which allowed us to verify the degree of usability and accessibility of the customized repository. For this, two tests were carried out with users, one with 7 blind and deaf people and the other with 5 people without disabilities, with different training and different professional activities, in order to establish a valid comparative framework.
The activities proposed were as follows: Visit the repository https://repositorio.info.unlp.edu.ar/, and carry out the following activities: 1. What is the purpose of this repository? What information is offered there? 2. The collections are published in communities. What communities do you find? 3. Name some papers published lately. 4. Name any degree dissertation you have found. Who developed it? 5. Name the works included in a course such as Algorithms 6. Regarding the experience you have had with the site: 1. Was it easy to use? 2. Could you find the information you were looking for quickly? 3. How did you find the organization of the site? The details of the tests with characterization of participants, methodology used and results obtained are presented below.

Experimental Test with Users with Disabilities
The experimental test with blind and deaf people was aimed at verifying the degree of accessibility of the digital repository with real users. This group works actively in the University Disability Commission of the UNLP.
For the development of the test, the group of people was cited on Tuesday, October 25, 2016 at 10:00 am in the Computer Science School of the UNLP. Table II presents the characterization of users with disabilities as considered relevant for this analysis. The usability test performed for people with disabilities, required some adaptations, unlike with the test with users without disabilities. In the first instance, it was necessary to adapt the PC room, reorganizing the desks, cables and plugs to guarantee easy navigation for people with blindness. The computers were adapted with screen readers as requested by the blind participants --some with NVDA and others with the JAWS reader. With regard to sound, they were also provided with headphones.
For deaf people, previous meetings with the interpreter were needed to ensure a complete understanding of the activity by the interpreter. We worked on the terminology associated with this method of testing beforehand, so that she could understand it and be able to transmit it to the deaf users.
After the adaptations mentioned, the methodology used was similar to that used with the participants without disabilities. There was a meeting with the 7 participants, where we explained the objective of the test, the procedure and that what was evaluated was the software itself and not their performance. This generated tranquility and confidence to approach the test. In addition, a general presentation of the site was made, without giving details as to its interface. When asked if they had any doubts, the first thing they asked was if they could ask for help, and they were asked to try to do the tasks on their own in the time they deemed necessary, because the idea is to test if the software is simple enough and accessible enough to guarantee autonomy. In the case of the deaf, the interpreter was asked not to influence the interaction.
After the presentation, they began to carry out the activities, and their interaction was monitored and recorded through direct observation. At the end of each activity the evaluator sat next to them to see if the task was completed or not, and, in case it was not, to inquire about the reasons.
At the end of the whole test, there was a small interview with the participant, so that they could describe their experience, their degree of satisfaction as well as their opinions, criticisms and suggestions.
The forms where the aspects of interaction between the person with disability and the site were recorded were designed to be simple, considering aspects of efficiency and efficacy. Regarding efficacy, it was analyzed if the user could complete the task: the evaluator had to circle yes or no and list the reasons in the case of a negative. With regard to efficiency, time was recorded. The evaluator had to note whether the task was performed at Slow, Normal or Fast speed.
In the case of the disabled users, the interpretation of these values as well as the specification of these thresholds were adapted to the circumstance. In the case of the blind, there was extra time added due to the delay in locating the screen reader in the different parts of the page, listening to what the reader says, interpreting it and understanding it. The information read by the reader includes more information than shown on the page, e.g., in the case of a list, it mentions the existence of list items and how many there are.
With regard to deaf participants, they present difficulties with language and terminology, as their native language is LSA, Argentine Sign Language, and they learn Spanish as a second language. Although they had intermediate PC knowledge, the terminology and concepts employed on the site were completely new. This also required more time. For such reasons, slow in this case refers to an average delay of 20 minutes, normal refers to a time of completion of approximately 15 minutes, and fast would be 10 minutes.
These thresholds were different in the case of participants without disabilities (slow, 15 minutes, normal, 10 minutes and fast, 5 minutes).
All participants were able to complete the proposed activities, at a time considered normal between 11 and 15 minutes.
The results obtained are presented in Tables 3, 4 and 5.   The activities that took them the longest were 2) The collections are published in communities. What communities do you find? And 5) Name the works included in a course such as Algorithms Most agree that it is easy to find the purpose of the repository. Participants with deafness who reported an intermediate level of PC use did not have difficulties to complete the task in a time frame considered normal.
They agree that the organization of the site is a little complex and the location of the search engine is confusing, as well as the place where it is located and how the results of the search are presented. The terminological question was also raised. They got confused with the term communities, thinking it was people. They did not understand the relationship between communities, collections and subcommunities.

Experimental Test with Users without Disabilities
In order to identify the degree of usability of the repository and as a complement to the tests with people with some type of disability, the same usability test was carried out with people without disabilities, with different training, professions and age related to the Computer Science School for different reasons. On April 10, a meeting was held in the School. They were explained the general purpose of the test and the proposed activities. Each one performed the tasks in an individual way that was monitored and registered by the evaluators through direct observation. At the end of the activities, the free questions generated debates and proposals for improvements to be analyzed and implemented. Table 6 presents the characterization of each of the participants. Regarding activities 1) to 5), all could complete them in a period of time of 7 minutes on average, considered normal, as can be observed in figure 9.

Figure 9:
Usability test with users. Time for each participant ("Test completo duración en minutos") for activities ("Actividades") 1) to 5) The subsequent exchange deriving from the free questions was very rich, generated a lot of interest and worked for other functionalities such as general search by letter, the extension to related resources in the School library and new services such as resource search from the virtual platform.
It can be observed that activities 2) and 5) are the ones that register the greatest amount of time to complete, just as with users with disabilities. The reasons put forward are similar, "the terminology of communities and subcommunities is unclear" "dissertations and final papers is not understandable", "presentation of search results is not clear and is not organized by criteria." As a conclusion of both experimental tests, carried out on the personalized digital repository to enrich the experience of use together with the previously mentioned accessibility adjustments, we can conclude that it is easy to navigate the repository, understand the objective and find material by different criteria. However, it is necessary to adjust the search engine and include aids that facilitate terminological understanding. The participants of both tests were able to complete all the proposed tasks and, with the modifications made, disability is not a limiting factor for interacting with the portal and accessing the information published there, reaching the proposed objective.

Modifications Performed
In the first instance, we worked on the findings from the first test, the use of Google ChromeVox and the validator Examinator. Based on the difficulties encountered with the Google ChromeVox tool and the comments relieved in the first test regarding the search option, it was decided to perform a refactoring in order to make it more understandable. In the new design shown in Fig. 10, when the browser screen is positioned on the search engine, the text reads search in the repository ("Buscar en el Repositorio") that is associated with the "title" attribute of the text field type input. In turn, the submit button of the form was modified, so that it is similar to that of a standard search engine, and a screen browser identifies it with the text search ("búsqueda") instead of go ("ir"). The search options were deleted, since based on the current structure of the repository, they could confuse the user. To solve the problem related to keyboard navigation, internal links were added in different sections, for example a link was added on the front page of the site pointing to the main section, this allows the user to directly access this section by activating it, so they would not need to go through the other sections if they do not want to. A link was also added to access the search options directly, and another to go from the options to the main section.
From the evaluation performed with the Examinator tool, multiple problems appeared that needed solving. In order to solve the problem where the lists according to different criteria had the same title, referring to local listings in the community or collection, as well as to global lists, the text of the links of local listings according to the situation was modified, as seen in Fig. 11. To solve error number 5, present since several elements of the repository used the attribute "id" to establish the style, it was decided to replace this attribute with "class" and modify the styles according to this update. In addition to correcting the errors pointed out by the tool, modifications were made to the style of the site in order to have a more liquid design. This is useful since it allows users to increase the size of the letters within the site, among other advantages.
The report that appears in Table 7 shows how the modifications made greatly improved the accessibility of the site, with respect to each of the existing disabilities.
Different words for different thinks. For example, Authors global sites or Authors of specific collections This report also shows that the site obtained an overall score with a value equal to 9.1 and with respect to each of the particular disabilities the results were: • Total limitation to see: Score 9.1 (11 tests) • Severe limitation to see: Score 9.1 (10 tests) • Limitation of upper limbs: Score 9.2 (9 tests) • Limitation to understand: Score 8.6 (7 tests) • Limitations derived from age: Score 9.1 (10 tests) In order to overcome the difficulties found in sending an item as mentioned in the previous point, the section of the form was divided into two separate sections, the first, shown in Fig. 12, includes the item's own data, such as title ("Título"), another titles ("Otros títulos"), date of publication ("Fecha de publicación"), reference ("referencia"), series ("Series"), type ("Tipo"), language ("Idioma"), programming language ("Lenguaje de programación"), operating system ("Sistema operativo") and license ("Licencia"). In the second section, the data of the authors ("Autores"), Responsible teacher ("Docente ) and other people related to the resource are shown, as seen in Fig. 13. This change is useful both in terms of accessibility and usability, first because a form so long and poorly organized makes it difficult for people with cognitive disabilities to use it. On the other hand, all users benefit from an organized form in a clear and concise way, so this also improves its usability.  Within the form, the required fields were indicated with an asterisk, which was not very clear for people with visual difficulties. To solve this, the asterisks were replaced with the text "required field". In turn, fieldsets and labels for fields that were needed were added.
An additional aspect that is being worked on in order to improve the accessibility of the repository was the handling of videos within the repository. Institutional videos are published that comprise the diversity of activities that take place within the School. The videos published are hosted on a specific YouTube channel, so it is possible to access them from this platform, or through the player included in the repository. To improve the accessibility of the videos in the repository, users are encouraged to use the HTML5 YouTube player instead of Flash, since the latter presents several problems to be handled with the keyboard. In addition, a link will be added to the Amara tool [30], which allows users to upload subtitles to be associated with each video.

Conclusions
Integration between platforms has been taking place for a long time in the framework of a global project that is developed at LINTI. In a first instance, through LMS Moodle communication with academic management systems, social networks and digital repositories. In a second instance, progress was made in extending the functionality of the repository to allow communication with other tools that are widely used today, such as file management systems in the Cloud, DropBox and Google Drive and the social network Facebook. The built-in extensions aim to extend the repository's own space in order to integrate it into new generation platforms that change the habits of information use. The repository is based on a free software platform, which allows its customization and adaptation to the needs of the project at hand. However, the adoption of an open tool also implies the verification of its accessible characteristics. It is essential that the tools made available can be accessed by anyone, independently of their capabilities and resources. The evaluation of the accessibility aspects of the repository and the correction of existing errors began in accordance with Act 26,653 enacted in Argentina on compliance with the WCAG guidelines for the web content of State sites.
The methodology used to verify the degree of accessibility of a website, in agreement with WCAG-EM, involved usability testing by experts, automatic validations using two of the tools present in the market and a tool developed entirely at the LINTI. Two experimental tests with users with and without disabilities allowed achieving a better knowledge of the accessibility guidelines that the platform fulfills and directing the efforts to overcome the disadvantages that are presented and reaching the AAA criterion of conformity. As described in the article, we traveled an important path along the way to obtain an accessible site from a free software product, an objective that is of the utmost importance for the inclusion of all in access to information. The task performed so far included the correction of errors according to the reports of the first evaluations carried out, and the adaptation of some aspects of the interface and the functionality to facilitate the use of the platform. In relation to this, aspects of navigation of the site were corrected so that the different functions could be located more easily and the access to the global search engine and the lists that adjusted the resources according to different search criteria was adjusted. Although several difficulties were solved, there is still work to be done in relation to aspects of functionality. A specific case is that referred to the set of entry forms, which is extensive and in some cases difficult to be completed by blind people. Although we started working in this direction, there are still points to be analyzed and optimized.
The tests performed with people with some type of disability were more than productive, as they allow to detect drawbacks in the understanding of some screens and in the access to specific forms present in the repository. While they were able to complete the requested activities, all users agreed that the organization of the search results was somewhat confusing, in agreement with users without disabilities. On the other hand, they agreed that the organization of the site was complex because of the location of some of its features. As a next step in refactoring, we are analyzing a rethinking of the terminology used in the platform and the organization of some content related to the results of the searches, put in focus by the suggestions made by the participants of the test carried out recently.
The results obtained with all the evaluations that were carried out, allow us to make an overall analysis of the aspects related to accessibility seen from different perspectives. This allows us to continue the work of adapting the repository to comply with accessibility standards in order to obtain a tool whose access is not limited by the capabilities of the user. It is expected that the modifications made may represent a set of good practices to be taken into account by educational institutions when implementing academic platforms.