A multi modal interface for a visually impaired pupils educational environment

The aim of this paper is to describe a multi modal user interface integrated within an architecture allowing visually impaired pupils and sighted people to work on the same station. This architecture is developed to face the problem of the inclusion of visually impaired pupils in mainstream education. The system is able to display the same original multi-media content converted in different ways on screen, Braille terminal and vocal synthesizers. It accepts various interactions from keyboard, Braille bar and mouse. Both blind and sighted users can manage the same tools, cooperate together on the same content, and thus perform the same activities. Blind pupils may be assisted by sighted teachers or tutors that don’t know how to read Braille characters

Libbraille : a portable library to easily access Braille displays

Abstract: The TiM project intends to develop and to adapt computer games for visually impaired children. In order to achieve this project a library which allows to easily access Braille displays was developed. This library provides all the functions needed to write text on the Braille display, directly raise Braille dots as well as receive the keys pressed on it. On top of that this library works with many different types of displays and is freely reusable. Introduction The TiM Project The overall purpose of the TiM project (Tactile Interactive Multimedia computer games for visually impaired children) To reach the needs of the children aimed by the TiM project, the platform is able to render those games to all the specific devices they use, each are corresponding to a specific modality: tactile boards, Braille displays, speech synthesizers and customizable graphical displays (scalable font prints, adjustable colors and contrast...) Support of Braille Displays An important issue for the TiM project is to supply the support for as many existing models of Braille displays as possible, that are used currently and that each child may have, as well as being able to add drivers easily when a new model comes on the market. Indeed, Braille displays are generally extremely expensive (starting at 5000€). It makes it very difficult for organizations to have several different models to develop drivers and for users to buy a different model. Since there was no existing standard library to access Braille displays, it appeared that the development of a Braille library, Libbraille, was crucial for the TiM project. A Collaborative Approach The high cost of Braille devices, and the fact that many manufacturers do not release publicly the protocol of their devices, explain that there was no standard API for Braille displays. A way to bypass this problem appeared to make this a collective project. By allowing other people to use and improve the library to suit their own needs, we could share our improvements and finally correctly support a large number of devices. That is why the code of the library was released under the LGPL [LGPL] which is used by many projects including the famous GNU/Linux. This allows people to freely copy, distribute and/or modify the library as long as they provide their enhancements under the same license. Developers who want to use the library can freely link it to their programs without any restriction. The library was also designed so that it could be as generic as possible. This means that it should be used in any project that requires Braille functionalities. Indeed other projects had already been done that used Braille displays. Some like BRLTTY [BRLTTY] or BRASS [BRASS], where quite advanced, however they were complete screen readers and the Braille functionalities were not independent, so that it was very hard to reuse them in other projects. The protocols used in those programs were integrated in Libbraille when the license allowed that, but with a focus on re-usability. Features of the Library This library is responsible for all the low level interactions with Braille displays. Text can simply be written on the display, or Braille dots can even be directly raised independently. It is also possible to get the keys that have been pressed by a user when the device has such keys. Supported Displays Here Architecture The library is organized in a modular way. A first layer provides a simple API to developers through a set of functions starting with the braille_ prefix, like braille_init, braille_display or braille_read. At initialization and according to a configuration file, this first layer will load a device dependent module. This module implements the low level interaction with a given Braille terminal protocol and depends on the manufacturer and model of Braille terminal. This module must use a lower level layer that provides a set of common portable functions to all drivers in order to communicate through the serial port or the usb bus, or to log some debug information. Those low level functions are portable and simplify a lot the development of drivers that work on different operating systems. Internationalisation The TiM projects aims to access the widest possible concerned population, and in this focus, multilingual features has been integrated from the beginning of the development. Many different Braille tables are used in different countries and even among different users of the same country! Those tables make the link between the ASCII and Braille representation of a character. The library already supports the ability to switch between many different tables and a user can easily create his own. Virtual Driver A graphical virtual driver was developed which displays a virtual Braille keyboard on the screen. This allows developers to create Braille enabled programs, without owning an expensive Braille terminal for test purpose. Configuration of Keys Layout This features allow users to customize the layout of keys on the Braille keyboard by editing a configuration file and to switch between some configurations at runtime. This can be very convenient for users since then can have different key layout depending on the software or the context on which they are working. Usage Overview Initialisation and Closing Interaction with the Braille library is done through functions starting with the braille_ prefix 1 . Those functions are declared in the braille.h header. The braille_init function should be called before any other function of the library. It will load the correct driver then initialise and configure the Braille display. On the other side, the braille_close function must always be called when closing the Braille library. It will unload the driver, free resources and close the library. Displaying a Simple String The simplest way to write something on the Braille display is to use braille_display. It must be called with a string and will display that string on the display. braille_display("test started"); When displaying text, the Braille representation is calculated according to a Braille table which can be customized by the user. Advanced dots displaying There is a more complex function to display when a better control of what is displayed is necessary, for example when displaying something other than text. What will be displayed is a combination of text and a filter that directly manipulate dots, using the braille_filter and braille_render functions. Typing with the Braille Keyboard It is also possible to know which keys have been pressed on the Braille display with the braille_read function. This function returns a structure of type brl_key. This structure has an attribute named type concerning the type of key pressed. If this type is BRL_CURSOR, the code attribute contains the number of the pressed cursor routing key starting at 0. If the type is BRL_CMD, then a function key has been pressed on the Braille display. The code attribute contains a code depending on the function key. There are many codes which 1 The source code of a complete example is available in the annexes. can be found in the braille.h header file. If the type is BRL_KEY, then the user has pressed a standard ASCII code on its Braille display. The code attribute gives the ASCII value. Current Status and Further Works Libbraille is already a well working library used in different projects requiring Braille displays support. The Free Software model appeared to be an excellent model for the development of devices drivers and many users contributed to the project. Indeed other libraries were created following the same model for the TiM project (libspeech which can drives some speech synthesis and libboard a driver for tactile boards). The library is far however from supporting all the existing models of Braille displays. This can only be achieved if this library is advertised enough so that owners of those devices can collaborate to improve the library... The following enhancements are also planned to be included in libraille: • Support for more models of displays: it depends on the collaboration of people with those models or of manufacturers. The integration of recent USB models is currently under development. • Development of a simple configuration front-end: at this time, the focus has mostly been on the developer aspect of the library. It is planned to improve the user friendliness by adding a simple configuration back-end to configure the device model and the key layout. More information can be found at: http://libbraille.org Acknowledgement

Understanding algebraic manipulation: Analysis of the actions of sighted and non-sighted students

Abstract Doing mathematics still remains a challenge for non-sighted students. Communicating with their sighted peers or teachers while doing math also presents difficulties since they use different representation supports. Interaction on accessible mathematical interfaces has had promising results in browsing using braille and audio, but support for doing math requires further development. To date, there aren't many options regarding accessible support for manipulating expressions as it is regularly practised in the learning stage. We have carried out an experiment with sighted and non-sighted students with the aim to better understand the actions they perform while solving basic algebraic expressions, in order to design the interaction in a multimodal interface for doing math. Sighted and non-sighted participants solved four algebraic expressions orally, and sighted participants solved them in write as well. The results showed that the intentions of the participants were in conformity with the systematic application of algebraic rules, regardless of visual ability. It is suggested that success in the interaction design of the interface will depend on the degree of direct access to the expression terms, and the ease of use of features intended to minimise memory load

Near-Infrared Light Exposure Triggers ROS to Downregulate Inflammatory Cytokines Induced by SARS-CoV-2 Spike Protein in Human Cell Culture

The leading cause of mortality from SARS-CoV-2 is an exaggerated host immune response, triggering cytokine storms, multiple organ failure and death. Current drug- and vaccine-based therapies are of limited efficacy against novel viral variants. Infrared therapy is a non-invasive and safe method that has proven effective against inflammatory conditions for over 100 years. However, its mechanism of action is poorly understood and has not received widespread acceptance. We herein investigate whether near-infrared (NIR) light exposure in human primary alveolar and macrophage cells could downregulate inflammatory cytokines triggered by the SARS-CoV-2 spike (S) protein or lipopolysaccharide (LPS), and via what underlying mechanism. Our results showed a dramatic reduction in pro-inflammatory cytokines within days of NIR light treatment, while anti-inflammatory cytokines were upregulated. Mechanistically, NIR light stimulated mitochondrial metabolism, induced transient bursts in reactive oxygen species (ROS) and activated antioxidant gene transcription. These, in turn, downregulated ROS and inflammatory cytokines. A causal relationship was shown between the induction of cellular ROS by NIR light exposure and the downregulation of inflammatory cytokines triggered by SARS-CoV-2 S. If confirmed by clinical trials, this method would provide an immediate defense against novel SARS-CoV-2 variants and other inflammatory infectious diseases

The marine fish food web is globally connected

The productivity of marine ecosystems and the services they provide to humans are largely dependent on complex interactions between prey and predators. These are embedded in a diverse network of trophic interactions, resulting in a cascade of events following perturbations such as species extinction. The sheer scale of oceans, however, precludes the characterization of marine feeding networks through de novo sampling. This effort ought instead to rely on a combination of extensive data and inference. Here we investigate how the distribution of trophic interactions at the global scale shapes the marine fish food web structure. We hypothesize that the heterogeneous distribution of species ranges in biogeographic regions should concentrate interactions in the warmest areas and within species groups. We find that the inferred global metaweb of marine fish—that is, all possible potential feeding links between co-occurring species—is highly connected geographically with a low degree of spatial modularity. Metrics of network structure correlate with sea surface temperature and tend to peak towards the tropics. In contrast to open-water communities, coastal food webs have greater interaction redundancy, which may confer robustness to species extinction. Our results suggest that marine ecosystems are connected yet display some resistance to perturbations because of high robustness at most locations.Using a global interaction dataset, the authors quantify the distribution of trophic interactions among marine fish, finding a high degree of geographic connectivity but low spatial modularity.C.A. was supported by a MELS-FQRNT Postdoctoral Fellowship and a Ressources Aquatique Québec (RAQ) fellowship during the conception and writing of this manuscript. T.P., D.G. and D.B.S. acknowledge financial support by the CIEE through their working group programme. M.B.A. is funded through FCT project No. PTDC/AAG-MAA/3764/2014. A.R.C. is funded by a Natural Sciences and Engineering Research Council of Canada (NSERC) PGS-D scholarship. D.G., T.P., M.-J.F., P.A. and S.J.L. are supported by NSERC Discovery Grants. T.P. also acknowledges a FRQNT New Investigator award and a Université de Montréal starting grant. D.B.S. acknowledges support from the Royal Society of New Zealand (via Marsden Fast-Start No. UOC-1101 and a Rutherford Discovery Fellowship)

Effect of angiotensin-converting enzyme inhibitor and angiotensin receptor blocker initiation on organ support-free days in patients hospitalized with COVID-19

IMPORTANCE Overactivation of the renin-angiotensin system (RAS) may contribute to poor clinical outcomes in patients with COVID-19. Objective To determine whether angiotensin-converting enzyme (ACE) inhibitor or angiotensin receptor blocker (ARB) initiation improves outcomes in patients hospitalized for COVID-19. DESIGN, SETTING, AND PARTICIPANTS In an ongoing, adaptive platform randomized clinical trial, 721 critically ill and 58 non–critically ill hospitalized adults were randomized to receive an RAS inhibitor or control between March 16, 2021, and February 25, 2022, at 69 sites in 7 countries (final follow-up on June 1, 2022). INTERVENTIONS Patients were randomized to receive open-label initiation of an ACE inhibitor (n = 257), ARB (n = 248), ARB in combination with DMX-200 (a chemokine receptor-2 inhibitor; n = 10), or no RAS inhibitor (control; n = 264) for up to 10 days. MAIN OUTCOMES AND MEASURES The primary outcome was organ support–free days, a composite of hospital survival and days alive without cardiovascular or respiratory organ support through 21 days. The primary analysis was a bayesian cumulative logistic model. Odds ratios (ORs) greater than 1 represent improved outcomes. RESULTS On February 25, 2022, enrollment was discontinued due to safety concerns. Among 679 critically ill patients with available primary outcome data, the median age was 56 years and 239 participants (35.2%) were women. Median (IQR) organ support–free days among critically ill patients was 10 (–1 to 16) in the ACE inhibitor group (n = 231), 8 (–1 to 17) in the ARB group (n = 217), and 12 (0 to 17) in the control group (n = 231) (median adjusted odds ratios of 0.77 [95% bayesian credible interval, 0.58-1.06] for improvement for ACE inhibitor and 0.76 [95% credible interval, 0.56-1.05] for ARB compared with control). The posterior probabilities that ACE inhibitors and ARBs worsened organ support–free days compared with control were 94.9% and 95.4%, respectively. Hospital survival occurred in 166 of 231 critically ill participants (71.9%) in the ACE inhibitor group, 152 of 217 (70.0%) in the ARB group, and 182 of 231 (78.8%) in the control group (posterior probabilities that ACE inhibitor and ARB worsened hospital survival compared with control were 95.3% and 98.1%, respectively). CONCLUSIONS AND RELEVANCE In this trial, among critically ill adults with COVID-19, initiation of an ACE inhibitor or ARB did not improve, and likely worsened, clinical outcomes. TRIAL REGISTRATION ClinicalTrials.gov Identifier: NCT0273570